AW: Torque 4.0 plan

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.

T.

> -----Ursprüngliche Nachricht-----
> Von: Greg Monroe [mailto:Greg.Monroe@xxxxxxxxxx] 
> 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@xxxxxxxxxxxxx
> For additional commands, e-mail: torque-dev-help@xxxxxxxxxxxxx
> 
>