You are viewing a plain text version of this content. The canonical link for it is here.
Posted to torque-dev@db.apache.org by Thomas Fox <Th...@seitenbau.net> on 2011/05/05 15:31:07 UTC
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
RE: create package org.apache.torque.sql in torque runtime
Posted by Thomas Fox <Th...@seitenbau.net>.
> 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
RE: create package org.apache.torque.sql in torque runtime
Posted by Greg Monroe <Gr...@dukece.com>.
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.
As I said, I'm +1 on your original proposal. Go for it.
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.
-----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
RE: create package org.apache.torque.sql in torque runtime
Posted by Thomas Fox <Th...@seitenbau.net>.
> +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
RE: create package org.apache.torque.sql in torque runtime
Posted by Greg Monroe <Gr...@dukece.com>.
+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.
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...
-----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
Re: create package org.apache.torque.sql in torque runtime
Posted by Thomas Vandahl <tv...@apache.org>.
On 05.05.11 15:31, Thomas Fox wrote:
>
> 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)
>
+1 Good Idea.
> The affected classes would be Query, SQLBuilder, JoinBuilder and
> SqlExpression in org.apache.torque.util.
I remember using one of these to extract the actual table name from a
column name (for a multi-table getColumnByPeerName()). Would be nice if
some of this would stay public.
> Any objections ?
No. Go ahead!
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org