db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henning P. Schmiedehausen" <...@intermeta.de>
Subject Re: [J2] Vote: Torque schema generation problems - how to proceed?
Date Thu, 09 Dec 2004 15:51:06 GMT
Ate Douma <ate@douma.nu> writes:

>>>- order of drop, create table statements causing conflicting result for
>>>  different database:
>>>  - for hsql a detail table must be generated (thus dropped) before the
>>>    parent table otherwise a fk constraint violation is thrown
>>>  - for mysql (also with innoDB) the foreign keys are generated inline and thus
>>>    changing the order doesn't help: we need to drop the child table (or constraints)
>>>    by hand, something Torque doesn't help us with
>> This is difficult to achieve IMHO because the sequence of the tables
>> is controlled by the Control.vm template and does not vary for the
>> different databases. It _should_ be possible to suppress foreign key
>> checking temporarily thus allowing arbitrary creation sequences with
>> some databases but I am no real wizard here. This needs more input
>> from other developers / users.
>I think the suggestion made by RaphaŽl Luta on the jetspeed list to first drop
>all the foreign key constraints would do the trick. Maybe that won't be too
>difficult to implement?

That could probably be done. However it would still mean some
rewriting of the templates, because currently the processing goes like this:

for (all table templates in the database)
 - setup parameters
 - parse Table.vm for this table

with table.vm loading e.g. drop.vm and then build the table itself. As
you have already noticed, some databases (MySQL noticably) build their
foreign key relations inside the table, others (PostgreSQL) outside
with explicit CONSTRAINT statements. 

To change this, we would have to change the loop to

for (all tables in db)
  drop constraints (if external)

for (all tables in db)
  drop tables

(these two probably optional

for (all tables in db)
  create tables

for (all tables in db)
  create foreign and primary keys (if external)

Bigger problem would be tables that have foreign key relations. In
that case, we would need to reorder the table sequence so that no
foreign key violations happen.

The funny thing is, that for my current project, I have already
written such a table sequencer (because I had exactly the same problem
(though I "only" nuke the table contents and do not drop the tables).

Ah, I do need to spend some time with Torque...

>> Yes. Torque is "all or nothing".
>So, schema updates would always need hand coded scripts if we stick with Torque if
>I understand you correctly.

Schema updates would (as far as I can understand this) be a "diff"
between two revisions of a schema file. I'm very interested in this
and how to do it (if commons-sql can do it, cool). However, at the
moment, Torque cannot do this.

(commons-sql has been incepted by the same people that, at some point,
dropped development on torque. The fact that commons-sql sat in the
Apache CVS for > 2 years before any activity picked up again and in
the meantime, no one worked on it makes me wonder if all the
advertised features really work or if it is just a "Work in
Progress". I don't know, haven't checked it yet).

>>>- no direct execution of ddl/data sql from xml, only through first written out
>>>  scripts. For execution at runtime from a portal/servlet application this isn't
>>>  but not exactly what I really would like.
>> Correct. The whole generator has been designed as an additional
>> wart^W^Waddition to ant. It definitely needs refactoring and
>> personally I want to look into dropping the whole Velocity
>> templating/Texen shebang. Texen has given us nothing but headaches
>> starting with logging and error reporting and ending up with gobbling
>> up memory like mad... Personally, I believe an XSLT solution would be
>> nicer but I sorely lack time to do any work on this ATM.
>That would mean a quite a rewrite of the generator I think. I wonder if
>that would be very profitable in the light of the commons-sql already able
>to do this...

To tell you the truth: The generator is not really great. It barely
does its job but any extension or additional functionality is really a
PITA. Rewriting it is very high on my list of stuff to do. 


>> I've read about commons-sql (it will probably move to the DB project
>Do you have any more information about that? Probability, timetable?

Probablity: 100%

Timetable: the next few days. The discussion is _now_ happening on the
PMC lists, that's why I read about it.


>> Even JvZ has admitted that introducing Jelly was a mistake. :-) 

As far as I can see, Jelly _is_ one of the cornerstones of
commons-sql. This looks better than Velocity in some places. Must look
deeper into this.


>But, to be frank as well: what would your suggestion be?
>Stick with Torque and work through all the issues which will take a lot of time as you
>and might even never be resolved fully, or start investigating a possible migration to

I just did a quick look over the code and found:

- commons-sql has been inactive for almost two years
- some activity has picked up this year, but the site
  is outdated and the CVS shows not much activity
- It depends on a number of snapshot jars 
- it has no release yet.
- it is also (like torque-gen) missing any object types outside
  the database/table/column scope (sequence, view..) which are
  necessary to model your database fully. Hibernate is better here.

Personally, I wouldn't hold my breath for this. It definitely needs
work (e.g. there is no MySQL 3/4.0/4.1 distinction, same problem as
torque-gen) just as torque-gen.

>But, my time is limited and I really would like to keep my primary focus on Jetspeed-2
>not get lost in DB configuration problems.
>So I'm not convinced (yet), certainly not after your frankly given response on the current
state of Torque,
>we should wait and see.

I don't know about the deeper issues aside from the few mails in this
thread. It all boils down to "how deeply is J2 entwined with
Torque". If your answer is "not much", trying something like OJB might
prove to be the better way. Moving from torque-gen to commons-sql
looks more like a sideway move to new problems to me.

>My impression right now is that we have a much closer match with commons-sql already and
that our
>near future needs (schema updates, direct ddl/sql execution) will prove that even more

As I said above: JMMV.

Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/

RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
   Linux, Java, perl, Solaris -- Consulting, Training, Development

What is more important to you...
   [ ] Product Security
or [ ] Quality of Sales and Marketing Support
              -- actual question from a Microsoft customer survey

To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

View raw message