http://share.whichever.com/ - this is the site where youy will find Village.
> -----Original Message----- > From: Chris Felaco [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 14, 2003 2:40 PM > To: [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: Torque performance problems > > > Stephen Haberman <[EMAIL PROTECTED]> 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-> [EMAIL PROTECTED]> > > For additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
