Hi Ate,
As the person who introduced Torque Generaration into J2, I just wanted to give my 2 cents.
Initially I ran into the same problems as you did, especially in bugs in Torque Gen velocity templates for HSQLDB. I was initially maintaining my own set of velocity templates, but in the intention of submitting all modifications, especially bug fixes back to Torque. The idea was that it shouldn't be the responsibility of the J2 team to maintain a DB generation tool if it can avoid it.
The biggest problem I encountered seemed to be the lack of activity in the Torque team, so my patches were slow to come through. I hope this is better now but I don't know.
I also really like your idea of being able to also use a DB tool to populate the database, and not just create the schema. If I can I will help, as I also have this problem when I integrate J2 with my project.
If I step back for a minute, the initial goal of introducing Torque gen was to have a way to easily support multiple databases, without having to maintain DB-specific scripts. I looked at alternatives too but I couldn't find any free tools except for Torque Gen and OJB's gen tools, which seemed even less advanced than Torque.
Have you talked to the Torque guys about the issues we are having in J2 ? Maybe they will be receptive to them and we can work out something with them ?
Regards, Serge Huber.
Ate Douma wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
