Hello.
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.
I found next information. http://incubator.apache.org/derby/papers/versionupgrade.html This seems to be corresponding.
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.
Well ... My decision is to start implementing option1. And option2 and option3 are to be left for future develpment.
I seems to be unfamiliar with the process of open source yet ... Thank you for your advise!
Best regards.
/*
Tomohito Nakayama
[EMAIL PROTECTED]
[EMAIL PROTECTED] Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html*/
----- Original Message ----- From: "Daniel John Debrunner" <[EMAIL PROTECTED]>
To: "Derby Development" <[email protected]>
Sent: Thursday, April 21, 2005 12:40 PM
Subject: Re: [jira] Commented: (DERBY-167) Inserting values in an identity column
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.
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.10.1 - Release Date: 2005/04/20
-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.10.1 - Release Date: 2005/04/20
