> > ... > > Ah ok, you are using the sql->xml part of the generator ? This is indeed an > > area where noone else of the torque developers is really interested in;
> May I ask why ? I had guessed that in the past as a user, but is > something I don't understand. Forgive me, but personally I think reverse engineering from the database is an inherent pain. You tend to loose important information, e.g.foreign key relation (at least using Mysql's MyIsam tables, not so sure for other DBs). Also, reverse type mapping can be difficult. In simple cases, you can guess the Java type automatically, but you will never get the Torque types booleanchar and booleanint back from the DB. And types might be different for every supported database. Getting ranges is difficult(can one determine that a column is varchar(134) or number(10,2) ? No idea.) Then, there's default value, no idea if you get that back. And so on. My energy is too limited for this wide field. The feeling between the Torque developers was that the reverse engineered file serves as starting point but must be tweaked manually afterwards. But I'm happy to be proven wrong.... > Is the scenario in which you have to write code for an existing db so > unusual? For me, it does not happen often. Usually the projects I do is developing from scratch. > The sql->xml is also useful when you change the db and you want to > regenerate the torque classes. How you do that: do you manipulate > manually the XML ? Yes, and create the alter table script manually. Altering an existing database requires good thinking and testing anyway most of the cases, so handcoding the SQL is the smallest part. > > we > > could use help in that area. In fact, while reorganizing the generator this > > is a part that still needs rewriting (in my opinion, throw out the > > ant/texen dependency and create front ends for the different build systems. > > > Different build systems ? What are you thinking about besides ant and > maven ? Only those two :-) But the old generator is strongly tied to ant which is quite pointless for the maven part. It is not a big problem, but the code is more complicated and heavy than it has to be. In my eyes, the better architecture is to provide the functionality in plain java (build-system-agnostic) and provide adapters for the different build systems. > > Maybe one could also use ddlutils (http://db.apache.org/ddlutils/), I did > > not check this). > I don't know the tool but I have had a look at the web site. In my > opinion the integration makes sense if the ddlutils heavily simplify the > actual code and the tool is widely used (which guarantees is powerful > and stable). > I see that they last released it in 2007, quite a long time. You are right, there is currently not much traffic there, but I'd guess Thomas Dudziak is still around. This was an idea to save double work in Torque, but I did not check in detail. For example, I'm not sure that ddlutils has maven support... But personally I'd leave that decision to the person who actually does the work. Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
