Mailing-List: contact ddlutils-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ddlutils-dev@db.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <43615AF8.3070705@mvdb.net>
Date: Fri, 28 Oct 2005 00:55:52 +0200
From: Martin van den Bemt <mllist@mvdb.net>
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
MIME-Version: 1.0
To: ddlutils-dev@db.apache.org
Subject: Re: The ToDo list..
References: <435E9D45.9010906@mvdb.net>
	 <224f32340510251552w2767b958r178104728f145794@mail.gmail.com>
	 <43613C94.7040807@mvdb.net>
 <224f32340510271438w4d01972cuf7fbe62c392fbbc7@mail.gmail.com>
In-Reply-To: <224f32340510271438w4d01972cuf7fbe62c392fbbc7@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

See inline :)

Thomas Dudziak wrote:
> 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.
> 

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