TomohitoNakayama wrote: > Hello. > > > I think the upgrade impact is very serious issue technically. > > Can you tell me more information about next ? > >> I know Dan is working on implementing the upgrade framework for this >> release.
Upgrade is a part of any Derby release, and traditionally it has always been made very easy for the end-user, namely adding the attribute 'upgrade=true' to a connection request that boots the database. Having a feature require upgrade involves more work, but it should not affect any decision on if the feature should be implemented. Now it may be best to see how the upgrade for a feature can be minimized, e.g. using existing system table columns is less work than adding system columns. > About solution 1-3, I think mainteanceability should be more discussed, > according to "http://incubator.apache.org/derby/#Easy+to+Use"; > As in my previous mail, I think solution 1 is most easy to use for user, > on the other hand , solution 2 and solution 3 will enable user to keep > their DB more proper. If you think about option 1) by itself, GENERATED BY DEFAULT, then it's in the SQL standard, and it's a useful feature. On that basis alone it's a good addition to Derby, and most likely a good medium complexity project to add to your Derby knowledge. Now just doing option 1) may not result in Derby-167 being fixed, but it is a good addition to Derby. > I think the decision should be made not only by me ... In a way, open source projects are based on decisions made by a single person, because they actually do the work and contribute the feature. It might be best for you to say which you are willing to work on and then see if anyone objects, I can't see any objections for option 1) and you say it's the easiest for the user. Thanks for getting involved in Derby! Dan.
