db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Monroe <Greg.Mon...@dukece.com>
Subject RE: create package org.apache.torque.sql in torque runtime
Date Fri, 06 May 2011 17:17:36 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.

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


Mime
View raw message