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 11:04:02 GMT

Henning P. Schmiedehausen wrote:

> Chris Custine <chris.custine@gmail.com> writes:
>>I think you may want to consider these items in the context of fixing
>>the total nightmare of using torque-gen with Postgres as well.  I have
>>posted several times about the hoops I jump through to get JS2 and
>>Postgres to work together, and your suggestions look like a good
>>opportunity to fix those problems with torque-gen and Postgres.  To be
>>clear, no single project is at fault (Postgres, Torque, or JS2), but
>>some minor bad choices in each are making Postgres support really
>>crappy right now in JS2.
> The Torque people right over there at torque-dev@db.apache.org would
> be really happy to know what you consider "total nightmare".
> (Personally I'm running a PostgreSQL based Project using sequences as
> ID generators with ~4000 tables in 52 schemas inside a database quite
> successful. All tables are generated an maintained by Torque and
> accessed through Torque and Hibernate).
> (Folks, if you have trouble with Torque and/or improvements or wishes,
> LET US KNOW!). Not many Torque people scan the lists of <arbitrary
> project>. Just come over to torque-dev or torque-user and tell us. We
> are not only willing to listen, we are even willing to act and improve
> our code to cater the needs of our users. That's what a project is all
> about.
Henning, thanks for the response and for scanning our list. Seems we aren't just
an arbitrary project to you at least ;-)

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.

I won't say it to be a "total nightmare". Really not.
But, right now, I don't think Torque is the best tool for the tasks we currently use it for,
nor for a few important additional tasks I would like to implement.

As far as I can see, Torque really shines where its Pear support is needed
(like in Jetspeed-1). But, for our Jetspeed-2 requirements which mainly concern
mapping an abstract schema definition and inserting initial configuration data,
the current torque generator features are not really sufficient, nor flexible enough.

After reviewing the generator and its templates I found the following lacking or missing:
- separate generation and/or suppression of drop table statements
- 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
- no support (as far as I could tell) for generating schema update scripts
- 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.
- data xml to sql translation is very limited. We at least need proper
   date and timestamp (in configurable format) value transformation support, as well as
   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
- 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

I've started reviewing commons-sql this morning. Although it is still in the commons sandbox,
I think it might be a (far) better match for our requirements.
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 and
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
codebase, the documentation also speaks of velocity support.
I haven't tested it out yet, so it is far too early to conclude it is what I'm looking for,
but it sure does look promising.

No disregard to Torque or its team, but considering our requirements and the current features
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).

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?

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.
If you respond, I'd appreciate it if you would send it to the jetspeed-dev list too.



> 	Regards
> 		Henning (Torque committer)

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

View raw message