db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <fisc...@seitenbau.net>
Subject RE: [Proposal] A general-purpose code generation framework for torque 4
Date Tue, 24 Nov 2009 21:13:52 GMT
Greg, Thomas,

Thanks for your reviews and opinions.

Greg Monroe wrote
> ...
> My first concerns are that this seems to be fairly complex and that as a
core
> part of Torque, there is a risk of overall reliability going down.

>From my "inside perspective", the code generator is not very complex. What
worries me most from a complexity viewpoint is the source transformation in
the templates. This needs to be better documented than it is now.

> I also worry that we may lose some functionality at least until it's
identified and
> restored.

The functionality which is currently not available is the external-schema
stuff. This could be implemented, but would add additional complexity and
tio be honest, I do not see the benefit of the feature.

The other functionality of the generator like sql execution etc would go
into other plugins searate from the code generator. I see no problems in
that.

> I'm also concerned that this major design shift might delay other things
that
> we've thought about for Torque 4.0.

I would see template modularity as a major 4.0 feature. I do not think that
it would be less effort to implement it in another way than in the proposed
way.

> Finally, I'm sure we agree that the Torque project would not be the final

> place for this.

Its scope is definitely wider than "just" an OR Mapper. But I do not think
this disqualifies it being one part of Torque. Maybe other people start
using it, but I'd welcome this rather than be afraid of it.

> I'm on the fence if it's best to "incubate" it inside the
> project or start it as a "Lab" project.

Labs does not allow releases, so it could not be used in Torque.

> Since it would be core to Torque,  I'm slightly more in favor of doing it
inside...
> and moving it out as it matures.

If the decision would be to use it inside torque (which is not yet
decided), there would only be two possibilities: Either put it inside
Torque or put it to Sourceforge with an Apache License.

Thomas Vandahl wrote:

> I'm afraid this could be a little heavy for the
> Torque purposes. My impression is that the template maintenance would be
> much more complex than before, but I could be wrong.

As I wrote above, I agree on the transformation side. Personally, I would
think that the opportunities outweigh the disadvantages, especially if some
more work is put into documenting the transformation code, but of course
one can have a different opinion.

> I thought it could be enough to generate JAXB-Sources from the schema,
> read it in, place the root element in the Velocity context and let
> Velocity do the work.

This would be another path to go. But just generating the model from the
schema would not bring any new features like modularity into the generator,
this would have to be programmed on top (this is certainly feasible, of
course).



So in the end, there are two questions to answer:
1) Do we want to use the proposed code generator in torque ?
2) If 1 is positive, should the code generator be inside or outside of
Torque ?

Are we ready to decide that, or do you feel that further discussion is
necessary ? No bad feelings from my side if the proposal is not accepted
into Torque, I was aware this could happen.

    Thomas


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


Mime
View raw message