db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cfel...@netscape.net (Chris Felaco)
Subject Re: Torque performance problems
Date Tue, 14 Jan 2003 20:40:26 GMT
Stephen Haberman <stephen@beachead.com> wrote:

>On Tue, Jan 14, 2003 at 10:37:37AM -0500, Chris Felaco wrote:
>> >- Separate the template based engine which creates java classes from
>> >  templates from the actual persistence code.
>> I'm not entirely sure what you're proposing here, but I think
>> you're suggesting keeping the save() and related methods out of
>> the OM objects entirely.
>No, I think he was suggesting that as it is now, the templates look
>public class $blah {
>#if x
>  protected int foo;
>#if y
>  public int getFoo()
>#if z
>    return x
>    return w
>So, this isn't a real code snippet. But having to do both
>persistence code generation and Java source generation at the same
>time sucks. My interpretation was that the Java source generation
>would be put in a seperate template based engine, then Torque would
>interact with a nice API and plug in the various bits of persistence
>code here and there (as templates).

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?

>> I'm not in favor of simply replacing the existing persistence
>> layer with any other persistence layer out there.  There are so
>> many APIs out there that it's hard to make sense of them all and
>> compare and contrast them.
>Precisely why we don't need to make another one. As long as we pick
>a good one, with community support, that 1-2-3 years from now will
>still be around and active/semi-active, I think it is a great boon
>for us not having to re-invent and re-debug and re-maintain the

Who is going to decide which API will still be around and active/semi-active?  I don't think
you will ever make universal consensus on that, and I can almost guarantee you'll regret the
choice down the road.  There are so many APIs, and most of them are good, but differ only
in the fine points of how they do things.  Some have abstractions for SQL queries, some don't.
 Some attempt to be a generic persistence mechanism using XML or serialization on the backend,
while others (like Torque) are pretty much tied to SQL.  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.  What you end up with is Torque as just an adapter for this other API, and
not a stand-alone product.

>If you want to spend the next few months/years designing,
>implementing, and maintaining your very own persistance mechancism
>embedded specifically into Torque, go ahead. But given that there
>are already viable, generic alternatives, I'd rather do that.

There really isn't all that much to design if we're just reimplementing the currently published
API. What I want to do is just fix the egregious performance problems in Torque so that the
basics of what is there now can be used.  If you for instance wanted to scrap the Criteria
code and use some other better SQL query abstraction, then that's a different story.  But,
if that's the case, then start something new and don't call it Torque.  I don't want to change
the overall design philosophy behind Torque, I just want to make it work better.

>> Torque should be self-sufficient if it has any chance of surviving
>> on its own merits.  If Torque is at the mercy of bugs in another
>> API, it's less viable. 
>If you pick a good API that is stable and released, this won't
>happen anymore than we have bugs in our own solution.

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 want to force
potential code contributors to Torque to have to learn yet-another 3rd party API?

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.

- Chris

The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

View raw message