Henning, thanks for your frankly given response.
Several comments further below.
Henning P. Schmiedehausen wrote:
Ate Douma <[EMAIL PROTECTED]> 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 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 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 sandbox, 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 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 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 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).
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 with 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 change 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 our 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
