db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <tfisc...@apache.org>
Subject RE: Torque 4.0 plan
Date Thu, 30 Nov 2006 22:54:21 GMT
On Thu, 30 Nov 2006, Greg Monroe wrote:
> ...
>> - 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

I'd volunteer to set it up. Maven 2 has a better multiproject support than 
maven 1, so some stuff will also be easier. Also, it is much faster on 
if there is trouble, we can still decide what we do when we have a 

>> - 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.

The generator is already quite a separate project which can be
used on its own. The only torque specific stuff now is the parsing of the
schema.xml and putting it into the database model. Ok, throw that out, and 
nothing is left of the generator as it is now, but here my idea was a 
replacement and not a slow migration. The torque specific stuff (no 
java, but meta-information) can go into the templates.

> Plus, is this competing with
> Velocity/Texen?

Well, my idea would be to support velcocity, of course, but also other 
templating languages like xslt, and also plain java. So it would be more 
powerful than texen, but yes, you could call it "competing" if you like.

> 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).

you mean something like the DoSelectJoinXXX() queries ?
> - 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).

I'm note sure whether this is the best possible approach. I'd rather work 
with a jdbc result set and generate a method that directly populates an 
object from the jdbc result set. This has the advantage that you can rely 
on type conversion of the jdbcDriver (getAsInt etc) and do not have the 
trouble to store which type which object is. It is also faster and less 

This can be achieved in two different ways. Thomas V's favorite is just 
calling an abstract method in BasePeer which gets overridden in each 
concrete peer and which is called for each row in the resultSet. something 

ResultSet resultSet = doSelectSomething();

and the createObject() method would be generated for each peer.

My favourite is to use an ObjectCreator class, which would be called for 
each row in a resultSet and create an object out of it. The concrete Peer 
itself could be the Object creator.

The first has the advantage of being the simplest possible approach, the 
second is more flexible (the method which does the selects and calls the 
ObjectCreator could be used for custom object creators, which use the 
values in the data row in any way they like)., and so provide a 
replacement for the doSelectVollageRecords, which is uften used for 
custom selects now.

> 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.

+1 (repeating myself)

> 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.

Not sure whether this would not get too complicated. Also, it would be 
difficult to achieve transaction support (the transaction would have to 
be kept open till everything is accessed).

> A GUID based idBroker method to autogenerate keys without
> needing access to a table.

I'm also not sure whether this is worth the effort. I'm sure the idbroker 
was gread when native id generation was difficult, but now I hold native 
id generation as the way to go. Why would one want to use the IdBroker in 
a new project nowadays ?


To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

View raw message