Hi Thomas,
Hi Martin, nice to have you here :-)
Thanx :)
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).
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.
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.
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.
Let me know what your opinion is on these things..
Btw my current main development is for hsqldb & mysql. I also have
access to MsSqlserver 2000 (and soon 2005) and Oracle.
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).
Sorry for the long mail :)
Mvgr,
Martin
I didn't plan to add DBUnit anywhere in DdlUtils, only provide a few
classes that can be used by somebody using DBUnit to utilize DdlUtils'
abilities regarding schemas and data insertion. Do you think that
providing an extension jar file containing only these class but
without the DBUnit jar is a problem ? It's not that important anyway,
but may be a nice thing to have and is not really difficult to
achieve.
Tom
