Hi! 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. bye Thoralf > -----Ursprüngliche Nachricht----- > Von: Thomas Fischer [mailto:[EMAIL PROTECTED] > Gesendet: Samstag, 30. September 2006 08:55 > An: [email protected] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
