db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Haberman <step...@beachead.com>
Subject Re: Torque performance problems
Date Wed, 15 Jan 2003 06:46:57 GMT
On Tue, Jan 14, 2003 at 03:40:26PM -0500, Chris Felaco wrote:
> It still does not compute with me, perhaps because I haven't been
> following the list much.  Are you suggesting that instead of 1
> template per source file, you would have templates for the code
> snippets and Torque decides where to use them and what data to
> pass them?

Kinda. I toyed with the idea awhile ago and it did not completely
fall together, but my basic idea was to make it layers. E.g. have
one layer, like BasicObjectLayer, that goes through each table in
the schema and creates a Java object for it (e.g JavaClass).

Then you have another layer, like GetterSetterLayer, that goes
through the schema, and for each table, add the private data members
and public getters/setters to the previously-created JavaClass.

Then if you want complex object model, e.g. doing the joins, etc.,
have another layer like AddSimpleJoinsLayer, then you go on to
AddSaveLayer, etc.

Seperating each of the aspects into their own given layer against
Java objects instead of hacking out raw source code would make it a
lot more elegant.

The one tricky part that I don't have elegantly figured out is how
to define the contents of methods. To remain usable, the Java
objects you are creating from the schema would be like JavaClass,
JavaField, JavaMethod, JavaImport, and that's about all you want.
You don't want to start generating JavaInt, JavaAdd, etc.

So to stay with the strength of Velocity, I was thinking method
contents could be defined as Velocity snippets which then when you
pay all of the JavaClasses to the code generation library, it does
all of the raw source code generation and includes the Velocity
snippets from the methods as it goes along.

> Who is going to decide which API will still be around and
> active/semi-active? 
<snip/>
> I just think betting the future of Torque on some other
> persistence API (especially one not managed by the Jakarta
> project) is not a good idea.

Jarkarta does have a persistence layer, OJB, that I'm willing to bet
will be around for while. They have a great community, which is why
they were let into Jakarta.

> Increasing the number of LOCs, and the number of interactions
> between APIs, will increase the overall complexity of the software
> and therefore make it buggier and more difficult to maintain.  One
> abstraction layer is better than two.  We all know JDBC, we all
> understand JDBC, why should it be so hard to build Torque just
> using JDBC?

Why do you think persistence frameworks are so popular? People see
how many LOC using a persistence framework saves them and come to
hate hand-coding JDBC when you can save entire native Java objects
with a few LOC.

I can guarantee that hacking out all of the various persistence code
and dropping in a framework like OJB would drastically reduce the
LOC in Torque.

>  Why do you want to force potential code contributors to Torque to
>  have to learn yet-another 3rd party API?

So you're saying any given project should only use it's own code?
And cross-project reuse should never happen? A developer of Torque
should never use an outside library, such as anything from commons,
as it is a 3rd party API that can't be trusted?

I'm sorry for taking your position to the extreme, but this is
effectively what you are saying: instead of relying on
currently-stable API's and implementations from the likes of OJB, we
should roll our own and/or evolve our existing dodgy implementation
to duplicate _the same functionality_ as OJB?

> Here's an example of what I'm talking about.  In Turbine 2.1, I
> ran into problems updating NUMBER columns in my Oracle DB simply
> because Village 1.3 was not using BigDecimal where it should have.
> I had a hell of a time just finding the Village source and any
> info about it.  I ended up finding the problem by using jad to
> disassemble the classes.  I toyed with the idea of just fixing the
> code in the disassembled class and packaging my own jar, but I
> couldn't bring myself to do it.  Then somehow by some miracle I
> was able to find the 1.5.3 version which had fixed the problem.
> The whole episode cost me at least a day of work to fix something
> that would have taken an hour to track down if the code had just
> been in Turbine.  And I still don't know how to find the source
> for village 2.0 which is included in Torque 3.0.

Yes, using Village is an iffy thing that was decided long ago in
Torque's past. E.g. three/four years?

Some reuse works, some fails. Village failed. But the reuse of ant,
commons-beantutils, commons-collections, commons-configuration,
commons-dbcp, commons-lang, commons-logging, commons-pool, jcs,
log4j, velocity, xerces, and junit, have all went well.

Given the ratio, I'd say, providing smart decisions were made about
the entire matter, reusing a persistence layer has a good chance of
succeeding.

(Also note that all of my comments are not items that I see being
done to Torque in the near future; evolution of the likes you
suggest is certainly welcomed to improve what is currently there.
But there is an awful lot of cruft that ideally when/if our two
current heavyweights, Henning and Martin, choose to fix up Torque,
they can hack out and replace with a cleaner design. And of that
cleaner design, I'm making the argument that a persistence layer
should be apart of it).

So currently this entire discussion is not that important, I'm
mostly just making my point for the sake of making my point. If you
still maintain your position that Torque should be it's very own
persistence layer, that is fine, I can understand and accept your
position. I just don't agree with it. :-)

- Stephen

Mime
View raw message