db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <fisc...@seitenbau.net>
Subject RE: newbie and generator rewriting
Date Thu, 11 Feb 2010 15:29:37 GMT
> > ...
> > 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
> > is a part that still needs rewriting (in my opinion, throw out the
> > ant/texen dependency and create front ends for the different build
> >
> 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
> > 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.


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

View raw message