db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fox <Thomas....@seitenbau.net>
Subject RE: create package org.apache.torque.sql in torque runtime
Date Sat, 07 May 2011 20:18:05 GMT
> Knew that moving the Criteria, et. Al. classes would be controversial,
> but thought I'd float the idea and see what others thought.  Not
> advocating strongly for this... just scratching the itch that the util
> package is wrongly named/used.  But sometimes you just have to live
> with past decisions on names/packages.

The door is not shut. If we find a good way to do it without headaches for
existing users, we can still do it.

> As I said, I'm +1 on your original proposal. Go for it.

Ok, will do.

> FWIW - I agree with Thomas V that we shouldn't be too aggressive in
> "privatizing" these classes... but we should be clear that these can
> change.  Which I think was your intent all along.

There will be nothing than convention preventing anybody from using these
classes. Users just cannot expect that these methods will remain unchanged
between releases.

     Thomas

> -----Original Message-----
> From: Thomas Fox [mailto:Thomas.Fox@seitenbau.net]
> Sent: Thursday, May 05, 2011 2:30 PM
> To: Apache Torque Developers List
> Subject: RE: create package org.apache.torque.sql in torque runtime
>
> > +1 on creating refactoring the util package.  I've often thought it
> > was overloaded/not named correctly for some classes.
> >
> > If we are doing this, should we also consider moving BasePeer,
> > Criteria, and Transaction as well?  IMHO, These are not utility
> > classes but part of the SQL Language modeling of Torque and
> > should be in a package that states this.
>
> I do not consider the the classes I want to move to be part of the public
> Torque API.
> I'd also not consider BasePeer public API in the usual sense (as usually
> not used directly by the user),
> but this might be open to discussion.
> However, Criteria and Transaction are certainly part of the public API
and
> I'd not be happy if these would be moved in a way that would require
> existing applications to be changed.
>
> Also, if we were to move those classes, I'd not move them into the sql
> package as they are SQL abstractions, not sql producing classes. I do not
> currently have a good idea for a package name.
>
> > This way we would have the om package for the data storage model
> > and the sql package for SQL actions model.
> >
> > The util package becomes more clearly the place for classes that
> > supply additional utility above the core.
> >
> > Of course, this may be too much refactoring and require lots of
> > Torque using code to be rewritten.... hmm, maybe we could leave the
> > current main classes in util as subclasses of the new classes in
> > the sql package, marked as deprecated and due to be dropped...
>
> This solution has a naming problem. Personally, my opinion is that
Criteria
> and Transaction are good class names and that the "real" implementations
> (which would be in the new package) should keep that name. But the
classes
> in util also should keep their names. To have two classes with the same
> name could lead to confusion for the users.
>
>    Thomas
>
> > -----Original Message-----
> > From: Thomas Fox [mailto:Thomas.Fox@seitenbau.net]
> > Sent: Thursday, May 05, 2011 9:31 AM
> > To: Apache Torque Developers List
> > Subject: create package org.apache.torque.sql in torque runtime
> >
> >
> > I'd like to create a new package org.apache.torque.sql for all classes
> > which main purpose is SQL generation and storage of SQL (but classes
> which
> > can be rendered into SQL like e.g. Criteria would stay where they are).
> > This would serve two purposes:
> > - The util package has become quite large and the sql generation
classes
> > serve a different purpose than most of the other classes (which are
used
> > directly by torque users)
> > - The sql package could be declared as torque-internal (i.e. it is not
> > considered API and we can change the method signatures there)
> >
> > The affected classes would be Query, SQLBuilder, JoinBuilder and
> > SqlExpression in org.apache.torque.util.
> >
> > Furthermore, I'd like to merge the SqlExpression code into SQLBuilder
(I
> do
> > not see any criteria to divide the sql generation code into these two
> > classes) and restructure the SqlExpression code a bit (it is currently
> not
> > very readable).
> >
> > Any objections ?
> >
> >       Thomas
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> > For additional commands, e-mail: torque-dev-help@db.apache.org
> >
> > DukeCE 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
>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message