db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thoralf Rickert" <thoralf.rick...@cadooz.de>
Subject AW: Need some more opinions on TORQUE-44
Date Fri, 06 Oct 2006 12:18:45 GMT

I'm not sure if I'm able to vote for this problem because I'm not a Torque-developer - so
I decided to make a comment that could be a "workaround" for the problem with Greg. :)

Because this bug seems nobody to disturb so far, we could remove the patch til we start a
new major release. I think, it isn't useful to create a branch for such situations with backward
compatibility problems or make switches or config properties to configure every littleness.
Maybe there could be a switch in the next major release that says something about "backward
compatibility" (which includes the problem with TORQUE-44 and other).

For me the actual situation is absolutly okay, because I've created my Torque objects and
I'll never change/regenerate them anymore. I think, the next major release produces a lot
of work for everybody who wants to use it, because of the plan to replace the village package.
This replacement means that everybody who makes more then a simple doSelect() has to change
the own code.


> -----Urspr√ľngliche Nachricht-----
> Von: Thomas Fischer [mailto:tfischer@apache.org] 
> Gesendet: Samstag, 30. September 2006 08:55
> An: torque-dev@db.apache.org
> Betreff: Need some more opinions on TORQUE-44
> 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

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

View raw message