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
building.
if there is trouble, we can still decide what we do when we have a
prototype.
- 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.
+1
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
memory-consuming.
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
like
ResultSet resultSet = doSelectSomething();
while(resultSet.next())
{
resultList.add(createObject(resultSet))
}
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.
+1
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.
+1
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 ?
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
