Mailing-List: contact torque-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Torque Developers List" <torque-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: domain of joe.carter@gmail.com
 designates 64.233.182.184 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=QI+54CizXATgxq61ZjsfwVLh851kh1uOPx0rxGZ6Q0SWGO1lotMRvqMt2BhTBZ0pRHoxEieR34uGs5xGpjqvmTP4Ankn7gbGsdTyo1WyRpqRpa/WVy1BXpFMn/mcHD5v3kAZaxgewMWzB2GesNfz3xcV0163EZbbdnoJl+iH0B4=
Message-ID: <21ca91ec0610081023rf3cc03j109daa0287676f6@mail.gmail.com>
Date: Sun, 8 Oct 2006 18:23:06 +0100
From: "Joe Carter" <joe.carter@excite.com>
Sender: joe.carter@gmail.com
To: "Apache Torque Developers List" <torque-dev@db.apache.org>
Subject: Re: Need some more opinions on TORQUE-44
In-Reply-To: <20060929232629.V54030@minotaur.apache.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_453_27312183.1160328186637"
References: <20060929232629.V54030@minotaur.apache.org>

------=_Part_453_27312183.1160328186637
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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 <tfischer@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
>
>

------=_Part_453_27312183.1160328186637--