Need some more opinions on TORQUE-44

[Thomas Fischer <tf...@apache.org>]

The problem addressed in

http://issues.apache.org/jira/browse/TORQUE-44

was that in java generation, the constants for Column names are generated 
in upper case, while in sql generation, case is preserved. So there 
is a msismatch between those two. This usually does not matter, as sql 
standard says that column name mathcing should be case-insensitive, but as 
usual, there are some databases which do not keep to the standard (in 
this case sybase)

So Thoralf went ahead and submitted a patch, and I committed it. However, 
if you change now from Torque 3.2 to 3.2.1-dev, the constants for the 
column names in generated java code change. So if one has stored these 
constants in some other place (like a database) in an application, any 
comparisons between the constants and the stored column names will not 
produce the same results as before, causing the application to fail. Greg 
ran into this problem in an application of his, so this concern is not far 
fetched.

The question is now whether we want to make this change in a minor release 
or not. So far, everybody has agreed that this was a bug when it was coded 
this way, but Greg's argument was that this behaviour has become a 
standard in some sense.

My personal opinion is +0.1 for changing the constants to preserve 
case, because it is not a big change and does not affect the "usual" 
Torque use cases. If we can not make such a small change, we would be 
reduced to nothing but fixing things which are obvious bugs between 
smaller releases.

I am aware that the best possible approach would be to use a svn branch 
for fixing obvious bugs, and another for stuff which might break anything, 
but this would need a lot of effort in merging and I do not see this to be 
justified (I know what I'm talking about here, having merged the 
3.1.1-branch and the 3,2-dev branch, and in some cases it was just 
praying that it woukld work out all right)

So please give your opinions whether we want to keep this change in the 
3.2.1 release or whether we should wait for a major release to put this 
in.

    Thomas






---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

RE: Need some more opinions on TORQUE-44

[Greg Monroe <Gr...@DukeCE.com>]

> My personal opinion is +0.1 for changing the constants to preserve
> case, because it is not a big change and does not affect the "usual"
> Torque use cases. If we can not make such a small change, we would be
> reduced to nothing but fixing things which are obvious bugs between
> smaller releases.
 
-1
 
For the change as is.. since there is no way to opt for the original 
behaviour.  No objections if it's reworked to include a build flag to
let the column case be choosen at generation time.
 

Duke CE Privacy Statement
Please be advised that this e-mail and any files transmitted with it are confidential communication or may otherwise be privileged or confidential and are intended solely for the individual or entity to whom they are addressed.  If you are not the intended recipient you may not rely on the contents of this email or any attachments, and we ask that you  please not read, copy or retransmit this communication, but reply to the sender and destroy the email, its contents, and all copies thereof immediately.  Any unauthorized dissemination, distribution or copying of this communication is strictly prohibited.

Re: Need some more opinions on TORQUE-44

[Thomas Vandahl <th...@tewisoft.de>]

Thomas Fischer wrote:

> So please give your opinions whether we want to keep this change in the 
> 3.2.1 release or whether we should wait for a major release to put this in.

+1 for keeping this change.

- The interface to the generated classes does not change, so everything 
should be fine for "normal use".
- Maybe we should consider to provide an API to query the column names 
as they are generated. This should allow even difficult cases to be 
resolved.

Bye, Thomas.


---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

Re: Need some more opinions on TORQUE-44

[Joe Carter <jo...@excite.com>]

Could the generated database be different with this new patch?
If so, that's a total showstopper for me.
And yes we use Sybase.

Instinctively I feel that behaviour changes doesn't belong
in minor point releases regardless though.

I'm not a developer, so just my 2p.

Thanks

Joe

On 30/09/06, Thomas Fischer <tf...@apache.org> wrote:
>
> The problem addressed in
>
> http://issues.apache.org/jira/browse/TORQUE-44
>
> was that in java generation, the constants for Column names are generated
> in upper case, while in sql generation, case is preserved. So there
> is a msismatch between those two. This usually does not matter, as sql
> standard says that column name mathcing should be case-insensitive, but as
> usual, there are some databases which do not keep to the standard (in
> this case sybase)
>
> So Thoralf went ahead and submitted a patch, and I committed it. However,
> if you change now from Torque 3.2 to 3.2.1-dev, the constants for the
> column names in generated java code change. So if one has stored these
> constants in some other place (like a database) in an application, any
> comparisons between the constants and the stored column names will not
> produce the same results as before, causing the application to fail. Greg
> ran into this problem in an application of his, so this concern is not far
> fetched.
>
> The question is now whether we want to make this change in a minor release
> or not. So far, everybody has agreed that this was a bug when it was coded
> this way, but Greg's argument was that this behaviour has become a
> standard in some sense.
>
> My personal opinion is +0.1 for changing the constants to preserve
> case, because it is not a big change and does not affect the "usual"
> Torque use cases. If we can not make such a small change, we would be
> reduced to nothing but fixing things which are obvious bugs between
> smaller releases.
>
> I am aware that the best possible approach would be to use a svn branch
> for fixing obvious bugs, and another for stuff which might break anything,
> but this would need a lot of effort in merging and I do not see this to be
> justified (I know what I'm talking about here, having merged the
> 3.1.1-branch and the 3,2-dev branch, and in some cases it was just
> praying that it woukld work out all right)
>
> So please give your opinions whether we want to keep this change in the
> 3.2.1 release or whether we should wait for a major release to put this
> in.
>
>     Thomas
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
>
>