db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "TomohitoNakayama" <tomon...@basil.ocn.ne.jp>
Subject Re: [jira] Commented: (DERBY-167) Inserting values in an identity column
Date Thu, 21 Apr 2005 13:54:23 GMT
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
         tomonaka@basil.ocn.ne.jp
         tomohito@rose.zero.ad.jp

         Naka
         http://www5.ocn.ne.jp/~tomohito/TopPage.html

*/
----- Original Message ----- 
From: "Daniel John Debrunner" <djd@debrunners.com>
To: "Derby Development" <derby-dev@db.apache.org>
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


Mime
View raw message