db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: [J2] Vote: Torque schema generation problems - how to proceed?
Date Thu, 09 Dec 2004 13:42:00 GMT
Henning, thanks for your frankly given response.

Several comments further below.

Henning P. Schmiedehausen wrote:

> Ate Douma <ate@douma.nu> writes:
>>Henning P. Schmiedehausen wrote:
>>In my initial message, http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=19387,
>>I described a few problems we are encountering with Torque right now.
> Just read it. 

>>After reviewing the generator and its templates I found the following lacking or missing:
>>- separate generation and/or suppression of drop table statements
> Yep. the drops should be turn-off-able using a property. They are not.
>>- 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?

>>- no support (as far as I could tell) for generating schema update scripts
> 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.

>>- 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 blocking
>>  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...

> Hibernate e.g. has a better solution by generating the creation SQL
> directly at run-time. We still shine at the source code generation for
> the classes/peers though.
>>- data xml to sql translation is very limited. We at least need proper
>>  date and timestamp (in configurable format) value transformation support, as well
>>  support for proper BIT mapping (an issue with PostgreSQL which seems to have
>>  been reported several times on the Torque list). Furthermore, I'd like to be able
>>  to use variables for values like $now or $yesterday, especially for date/timestamp
>>  fields.
> Support for custom functions would be nice, too (talk encrypting passwords...).
Yes. But if I read you correctly, we shouldn't expect those from Torque soon?

>>- overriding only a few generator templates (like the table.vm and tablefk.vm for
>>  to fix the mysql issue) requires us to maintain *all* templates: torque isn't able
>>  to resolve missing templates from the classpath if templates from the file system
are to be
>>  used.
> Texen again. I hope to become a velocity committer at some point (it
> was basically agreed upon at ApacheCon with Geir and Daniel but no CfV
> yet. :-( ).

>>I've started reviewing commons-sql this morning. Although it is still in the commons
>>I think it might be a (far) better match for our requirements.
> I've read about commons-sql (it will probably move to the DB project
Do you have any more information about that? Probability, timetable?

> (maybe make a short stint through the incubator) soon) yesterday. I
> haven't looked at it yet, but everyone that I hear talking about it,
> really likes it. So yes, I will definitely look at it.
>>Especially direct ddl/sql execution is provided as well as schema update at runtime
>>Its datatype mapping support also looks far more extensive (including number, date
>>timestamp format support) than what I've seen in Torque. I expect the PostgreSQL problems
>>Chris Custine has to be far less then we have right now with Torque.
>>Finally, it also supports (and uses) templating. Although I only see jelly scripts
(eek) in the
>>codebase, the documentation also speaks of velocity support.
> Even JvZ has admitted that introducing Jelly was a mistake. :-) 

>>I haven't tested it out yet, so it is far too early to conclude it is what I'm looking
>>but it sure does look promising.
>>No disregard to Torque or its team, but considering our requirements and the current
>>supported by Torque, do you think we should stick with it, or maybe better try commons-sql
>>(or even something of our own which I don't really want if not needed).
> Sure. Torque _is_ a smallish project and lacks in some aspects (you
> did manage to put your fingers on quite a number of sore spots in the
> generator. :-) ). Bad metadata for the DBs is another thing that I
> really hate.
>>We hope to put out the final release Jetspeed-2 early next year, and our current problems
>>the M1 release as well during development need to be addressed soon.
>>If you do think Torque can meet our needs, how much work and time would it cost?
> To clean up everything that you mentioned above? A lot. I freely
> admit, that for some things that you like to have (update scripts
> e.g.) Torque simply has not support. It was not really intended for
> this. For you immediate needs, I cannot give you an estimate or time
> frame, sorry. I will open a ticket for your points in the TTS so they
> won't be forgotten.
Thanks, I've already seen them.

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 said
and might even never be resolved fully, or start investigating a possible migration to commons-sql?

I'm more than willing to support the Torque team in resolving these issues if there is any
they can be resolved (within time).
Also, the initial response from other Jetspeed team members and users on the suggestion of
David Sean Taylor to try to fix the problems with the Torque team first is +1.

But, my time is limited and I really would like to keep my primary focus on Jetspeed-2 features,
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.

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

Thanks again for your response.

Regards, Ate

>>Thanks again for your response and I hope we can help each other out with this.
>>I just subscribed to the Torque user and dev lists and also sending this response
to the latter.
> Cool.
>>If you respond, I'd appreciate it if you would send it to the jetspeed-dev list too.
> Let's see if cross-posting with this newsreader works out... :-)
> 	Regards
> 		Henning

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

View raw message