From the various coments of the dev list, more than half of the people
would rather not change this behaviour in a bugfix release. So I'm going
to revert the change and reopen the bug, if noone vetoes this.
Note that this is not the end of the story, I'm convinced that this should
be changed in the next major release.
Thomas
On Fri, 6 Oct 2006, Thoralf Rickert wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
