db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thoralf Rickert" <thoralf.rick...@cadooz.de>
Subject AW: Torque 4.0 plan
Date Fri, 01 Dec 2006 17:30:00 GMT
I forgot something: We've implemented a "working" and easy way to use Aliases with JOINs. This
is necessary if you join a table twice. And the "Add full support for views" is something
that would be very useful.


> -----Urspr√ľngliche Nachricht-----
> Von: Greg Monroe [mailto:Greg.Monroe@DukeCE.com] 
> Gesendet: Donnerstag, 30. November 2006 17:29
> An: Apache Torque Developers List
> Betreff: RE: Torque 4.0 plan
> > Thomas Fischer said:
> > 
> > Now that the first Torque RC is outit is time to think about
> > what we'd like to do as next version. Personally, I'd like 
> > to propose the following:
> > 
> Can't complain about that list.  Only +0 items I'd list
> would be on the Maven 2 conversion and the generic generator.
> > - Switch to Maven 2 as build system. Maven 2 has much better 
> >   multiproject support than Maven 1, so building will be 
> >   easier.
> My +0 for Maven 2 is based on the little bit I dug into it 
> for the add-on stuff. It seemed to add a lot of complication 
> and extra more effort to do thing outside the "Maven 2 norm" 
> that was fairly easy in 1.  IMHO, build systems should take a 
> minimum of time away from your development time, not become 
> a subproject of it's own.  
> But to be fair, it could be I just didn't take the time to 
> learn it well enough. But if someone else is doing the work ;)  
> who am I to complain...lol
> > - Make the generator more generic. I'd like to turn the 
> >   generator into a generic code generation tool
> I'm +0 on the idea of the generic generator.  I can see the
> worth in this, but I'm not sure it's a core Torque thing. 
> It seems like this should be like Torque and Turbine, some
> of the ground work layed here but with a plan to split it
> off into a separate project.  Plus, is this competing with
> Velocity/Texen?  None of this is a show stopper, just thoughts
> for fine tuning the proposal.
> Here's some idea's I'll throw in the ring:
> Better support for non-record type queries.  I.e., the 
> stuff people do with executeQuery / Village Records.  Queries
> of this type that come to mind are:
> - Optimized Join queries that return data from multiple 
>   tables (for creating master lists).
> - Queries with functions.
> To support this and also assist in the Village exorcism,
> I'd propose making the BaseObject an actual storage 
> implimentation, like Village Record or ResultsSet.  Internally
> the data would be stored as objects in OrderedMap with the 
> getBy/setBy methods being the BaseObject access points.
> This would allow executeQuery to return a list of BaseObject
> records.
> Additionally, the generated record objects could make use
> of this new base class to support things like isNull() on
> primitives.  We could also use this to track modified and
> unmodified column values, which would be very useful (e.g.
> updating tables without primary keys). 
> Take a serious look at DDLUtils integration, and maybe do 
> a little encouraging to get that project to do a release/
> Maven repo set up.
> Some stuff that may be V4.5 features but might be nice to 
> start planning for:
> Add full support for views, since most of the common DBs
> support them. E.g., a way to define them in the DTD, 
> support for creation, etc.
> Look at being able to generate object level "views".  E.g., 
> I'm always creating "wrapper" objects that are based on 
> subsets of data from two or more related tables, with access, 
> load, and store methods.  I'm thinking this would be a way 
> to define business objects via XML and have them generated.
> Support for "lazy" record object population.  Sometimes it's
> better to retrieve a set of partially filled objects (e.g. 
> doing a master list), and only totally fill the object when
> needed.  Adding an isLoaded option to the isNull, isModified,
> column level tracking would make this fairly easy.
> A GUID based idBroker method to autogenerate keys without
> needing access to a table.
> 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

View raw message