db-ddlutils-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin van den Bemt <mll...@mvdb.net>
Subject Re: The ToDo list..
Date Thu, 27 Oct 2005 20:46:12 GMT
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">
        the mssql view select
   <sql platform="HsqlDb">
       the hsqldb view select
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 :)


> 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

View raw message