db-ddlutils-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Dudziak <tom...@gmail.com>
Subject Re: The ToDo list..
Date Thu, 27 Oct 2005 21:38:51 GMT
On 10/27/05, Martin van den Bemt <mllist@mvdb.net> 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.

> 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.

> 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.

> 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).
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

> 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 ?
Either way, I could start a vote for you for becoming a DdlUtils
committer on the PMC ?

> Sorry for the long mail :)

Don't worry :-)

Tom

Mime
View raw message