Team,
Today, I dived into our usage of torque and what we are getting from it. I didn't really know torque yet, but I was dismayed by what I encountered and how it is affecting the way we are configuring J2 right now. The problems with drop table statements and foreign key violations we have had recently (and still have) are really caused by the current (lack of) functionality of torque and its quirks.
After reviewing the velocity scripts used by torque, I can see these are easily fixable. But, it'll require heavy changes to them and therefore I'm not so sure the torque team would quickly accept them.
I would like to propose to create and maintain our own set of torque scripts instead of using the packaged ones. Because of the way torque processes these scripts, this will mean we need to maintain *all* of the torque-sql scripts: only supplying those which need to be changed won't do.
Maybe, after some time, our versions of these scripts can be incorporated back into torque, but that I don't find too important right now. I would like to get rid of several workarounds and auxiliary sql scripts we currently have to use just to get things working: - no need anymore for several drop goals and drop scripts - no need anymore for special instructions to get an initial installation on Oracle, nor post processing the oracle sql scripts to strip out unwanted drop statements - no need anymore for manual table creation on Oracle when a new table is added (no automatic solution possible)
Whats more, I would also like to get rid of all the different populate-userinfo-for-default-psml.sql variants. I looked into the capabilities (capability also being another issue with torque it seems on sybase: a reserved word) of torque on transforming data xml to sql. Well, don't hold your breath: it won't do right now.
Although the schema xml parsing engine is nice enough as it is, other than that I really don't see much added value for J2 as we also don't use the Peer functionality (which takes up by far the biggest part of its codebase).
What I really would like to see is an new/rewritten/forked torque implementation, only used for schema and (proper) data xml parsing which can both generate sql and/or perform direct sql/jdbc execution on the fly. Then we can provide schema installation (and upgrades! using version attributes in the xml) at runtime (optionally of course). New, but still missing tables, constraints, configuration data, et cetera could be created only when needed.
I don't think this would be very hard, nor too much work to provide using (only a small part of) the current torque codebase as starting point. If we would agree on this path, I'm more than willing to put in time realizing this goal.
Of course, I've been searching the net today for alternatives capable of this but really couldn't find anything coming near these requirements *and* with an ASF compatible license. Only hibernate has something like this build in (automatic schema creation and/or upgrade), but that one is off limits (isn't it?).
So, I'd like to call a vote on the following proposals: - maintain our own torque-sql scripts: [ ] - provide our own data xml to sql (torque based) scripts: [ ] - (re)write our own database config engine based on torque allowing runtime schema/data installation/upgrade: [ ]
Regards, Ate
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
