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 (asf.osuosl.org: domain of joe.carter@gmail.com designates
 64.233.182.186 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=iohb+y5jAAVOKoViUcpieXW9UYK6h52nMiK4s6tv/xXYmrVHOsTMecFzrk0FXJtF1jHo0RihSkTrvx3BFaPu1paHhPUzTQXIRrOYvIGkpYiRgIpFXR2Gftj7ThzDE12jJlSUUJbTIA2/bpbK+aRbpBcCv5NUZnDxE3Vj3VQfykw=
Message-ID: <21ca91ec0610200127u387d692co6e9274351ee6facb@mail.gmail.com>
Date: Fri, 20 Oct 2006 09:27:56 +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: 
 <OF8004D21E.42C53344-ONC125720D.002CAB4E-C125720D.002D0700@seitenbau.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_92904_30106607.1161332876834"
References: <8F5843B903F59D4C8C6806BB49A3911901B73F28@dukece-mail3.dukece.com>
	 <OF8004D21E.42C53344-ONC125720D.002CAB4E-C125720D.002D0700@seitenbau.net>

------=_Part_92904_30106607.1161332876834
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I've no problem with having the new behaviour in a new major release.
I'd expect to have to refactor to some extent for a new release.
The issue for me was that it was a minor bug fix release.

So I agree with you Thomas.
But if Greg can spare the time, it allows people to use the
new format sooner, which is also fine.

Thanks

Joe

On 20/10/06, Thomas Fischer <fischer@seitenbau.net> wrote:
>
> If you want to do that- great ! However, I'm not sure if we want that
> property in the long run. Personally, I'd think that we should remove tha=
t
> in the planned 4.0 release, to keep the amount of properties within some
> limits.
>
>     Thomas
>
> "Greg Monroe" <Greg.Monroe@DukeCE.com> schrieb am 19.10.2006 23:07:29:
>
> > Well, if nothing major breaks, I think I've got some
> > extra time.  So, how about the following to resolve this?
> >
> > I'll re-work the patch to have the old style peer names be
> > available by setting an optional build property?  So it's
> > a deprecated method that will eventually be trimmed.
> >
> > This way everyone wins. ;)
> >
> > > -----Original Message-----
> > > From: Thomas Fischer [mailto:tfischer@apache.org]
> > > Sent: Thursday, October 19, 2006 4:30 PM
> > > To: Apache Torque Developers List
> > > Subject: AW: Need some more opinions on TORQUE-44
> > >
> > > 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=FCngliche 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
> > > >
> > > >
> > >
> >
> > 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.
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>

------=_Part_92904_30106607.1161332876834--