db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Quinton McCombs" <qmcco...@nequalsone.com>
Subject RE: Torque performance problems
Date Tue, 14 Jan 2003 21:12:08 GMT
http://share.whichever.com/ - this is the site where youy will find
Village.

> -----Original Message-----
> From: Chris Felaco [mailto:cfelaco@netscape.net] 
> Sent: Tuesday, January 14, 2003 2:40 PM
> To: turbine-dev@jakarta.apache.org; 
> turbine-torque-dev@jakarta.apache.org
> Subject: Re: Torque performance problems
> 
> 
> 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
> >like:
> >
> >public class $blah {
> >
> >#if x
> >  protected int foo;
> >#if y
> >  public int getFoo()
> >#if z
> >    return x
> >#else
> >    return w
> >#endif
> >#endif
> >#endif
> >
> >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 wheel.
> 
> 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/downl> oad.jsp 
> 
> Get 
> your own FREE, personal Netscape Mail account 
> today at http://webmail.netscape.com/
> 
> --
> To unsubscribe, e-mail:   
> <mailto:turbine-torque-dev-> unsubscribe@jakarta.apache.org>
> 
> For additional commands, 
> e-mail: <mailto:turbine-torque-dev-help@jakarta.apache.org>
> 
> 

Mime
View raw message