See inline :)
Thomas Dudziak wrote:
On 10/27/05, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
At the time of moving the ddlutils from commons, I had too much
outstanding changes that needed to be in production, so I forked
commons-sql, using that fork for several projects. Currently I am
migrating back to ddlutils, so I can drop the (internal) fork. I am
depending on some extensions though that are (probably) not in the
current ddl-utils. One part is in the model : I added a javatype to the
Table, so I can use that to lookup the table that goes with a specific
object. This functionality is also pretty usefull for creating OJB xml
files (since they need that type). Also with Column I return the name if
the javaName is null, but I can move this one to my personal code (since
the model writer will else always write a javaName, even if you don't
want that).
That should be easy to add. DdlUtils does not use it internally (I
wouldn't know what for anyway), so that's probably only a single line
in the betwixt mapping and the corresponding accessors for Column and
for Table each - after all the DTD already contains attributes for
that.
In fact, there are a couple of attributes in the DTD that are
currently not represented in DdlUtils but that might be useful in the
API.
Why is the dtd used from torque, is this a mandatory dependency (I don't
know who actually heavily depends on ddl-utils)..
Another part is the JdbcModelReader. I didn't monitor if you did any
hacking on that one, but the at least the old modelreader is seriously
flawed, since the system doesn't do any mapping from native sql types to
ddl-utils generic types, which causes a lot schema comparisons (which I
use a lot) to say the real database is different from the xml model. In
general it is a big pain to import a model from eg mssqlserver and
directly use that model in eg mysql (eg type lengths are set when there
shouldn't be, dtproperties system table is imported, etc, etc). We will
hit some limits with this in the future, because of different
capabilities of the database system (ehh Platforms as it's called now),
but I think we can get it as close as possible.
That's the next big ToDo on my list. On (I think) this weekend I'll
integrate the public Api of the model reader into the Platform and
create a structure of the readers similar to the sql builders thus
allowing for database-specific handling. Once that is in place, I'll
probably add unit tests to ensure at least the roundtrip scenario, eg.
XML schems -> database -> XML schema generates the same schema.
Sweet.. I did some "reverse" mapping in my fork, so I could probably
port those mappings to the new stuff you'r doing..
Maybe we also need some integration test (sub) projects or (ant) build
conditionals, so people can test on a specific database when it's present ?
Also a big todo (not in a hurry on this though) on my list (I saw
something similar to the ToDo.txt in SVN) is upgrading from one xml
database model to another database model and therefore make use of the
version identifier in the Database object. Since moving from model to
model in most cases need some kind of conversion of data, we should add
some kind of way people can add a conversion strategy between 2 model
versions. First a simple API and maybe later some more specifics, based
on experience (eg documention, examples) of best practices in this regard.
Hmm, that might be tricky. Probably something for 1.1 or later.
What is necessary though is the completion of the existing support for
table alteration, esp. regarding foreign keys and the like.
I can have a look at that, but this heavily depends on the reverse
mapping working correctly. I also have a method called
isUpToDate(Database database), which could also be usefull in ddl-utils
and needs a good functioning reverse mapping..
Also support for views, triggers and stored procedures would be nice,
maybe starting of with simple support for them by means of pure sql eg
<table name="SiteView" type="VIEW" javaType="some.nice.type">
<column name="id" javaName="id"/>
<sql platform="MsSql">
<![CDATA[
the mssql view select
]]>
</sql>
<sql platform="HsqlDb">
<![CDATA[
the hsqldb view select
]]>
</sql>
</table>
This needs more consideration I you can imagine, though DynaSql would be
quite a nice fit for this and it allows easier migration from current
database schema's to ddl utils.
I'm not so sure whether that is something DdlUtils should provide (not
to mention that I got no control over the DTD so adding the sql is
tricky).
Can we drop that dependency on the torque dtd ?
Perhaps something better would be to allow extension points using the
constructs in the schema. Eg. when DdlUtils creates table A, then some
user-specified stuff might be executed before or after (think of
aspects). Per default this might be the plain execution of SQL.
This way, the database-specific stuff could be put into a separate
file with one file per database type which IMO makes a nice
separation.
E.g.
<extension table="A" for-action="creation" application-type="post">
<sql>
...
</sql>
</extension>
or something of the like
Seperating conceptual and physical schema is a cleaner approach indeed.
Btw my current main development is for hsqldb & mysql. I also have
access to MsSqlserver 2000 (and soon 2005) and Oracle.
That's cool, esp. regarding Sql Server which is notoriously difficult.
Btw I tried committing a couple of times in the past, but I don't seem
to be a member yet, do I have to ask the db pmc to make that happen (I
can see if I can find the original move request if that helps).
Yep, I think so, though perhaps I should do that. Do you already have
commit rights for any DB project ?
Nope, not committer on a db project yet, so I am probably not in the db
group (if that is needed at all with svn?).
Either way, I could start a vote for you for becoming a DdlUtils
committer on the PMC ?
Sounds good to me... If I need to do anything for this, let me know..
Mvgr,
Martin
