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/download.jsp
Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
