Daniel Rall Said:
> That's a very interesting idea. Have you implemented it? If so, what
> are the pros and cons you've encountered vs. Java-based SQL
> definition? It could probably be rigged to generate compile errors
> for schema changes, just as Torque-based SQL does...
I have implemented it, except that it used a generic object for processing.
Generating Java would be a half step up. (I didn't have Velocity then.<g>)
Pros:
* Easy to get data EXACTLY the way you want in and out of the database. You
write the SQL then you plug it into the XML. This includes Stored Procedures.
(I know this will raise the classic DB dependence response - but that horse has
been beaten to death. If you want DB independence then write portable SQL.)
* For DB intensive applications it allows you to leverage the DB tier to get
more performance from the app server. Pushing data manipulation logic into DB
where they run faster and where there are usually more CPU cycles to burn.
* Easy to modify SQL for optimizations and additional elements.
* Allows you to leverage SQL for early formatting of output. For example Last
Name, First Name can be done in SQL directly.
* Allows you to easily verify (test) ALL SQL in the system. We had one test
that ran all SQL so if you add new SQL you don't need a new unit test.
Cons:
* Positional column references are a pain to debug if they are off by one. We
alleviated this by verifying that column counts matched. Another approach is to
bind the columns to the statements in the XML using a logical reference. A
little more work may be worth it.
* The Java Generation step could get in the way. A SQL change would require a
texen gen and a compile. (Not big deal to me.)
I really liked working with a system like this. All the other ORM tools I've
worked with just got in my way.
> > Think of it as an extension to torque. The difference in this approach to
> > torque is that the SQL is hand written and then the objects are
> generated off
> > that (instead of off the tables). So you can execute the exact SQL
> you want.
>
> Huh. I'm quite partial to the way that Torque currently functions.
> An extension would be good, but I would like to preserve the existing
> functionality as well.
I would propose providing this layer on top of what you get with Torque not
replacing Torque. I think they are complimentary.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
