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: Torque 4.0 plan
Date Thu, 30 Nov 2006 16:29:12 GMT
> 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

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

View raw message