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: Some ideas for dynamic configuration of Platform implementations
Date Fri, 06 Oct 2006 17:48:14 GMT
On 10/5/06, David Sills <DSills@datasourceinc.com> wrote:

<snip>

> You will note that comparison with the current MSSqlPlatform class makes
> it perfectly clear that these are simply equivalents with XML markup. (I
> haven't been through every Platform implementation yet, so this is still
> subject to minor amendments, of course).

While this looks quite good, there is one big problem in that the
mapping is bi-directional. That is, it not only defines hwo to map
from JDBC type to native type, but also vice versa. And therein lies
the problem as it is much harder to declare these backmappings. E.g.
have a look at the Oracle and Firebird model readers, and you'll see
what I mean.

> You will note that I left the manner of obtaining this value object
> unspecified above. My idea was to have a singleton factory that
> statically loaded all the XML files it could find at runtime (it might
> know about them, do Java discovery to get a list to look up, or simply
> find them by a naming convention). It would be my idea, as you can see,
> to acquire the XML files as classpath resources, so as to make it simple
> for anyone to substitute for any of the files they like by simply
> putting their replacements earlier on the classpath. This would probably
> be made easiest (though it's a little restrictive) if the factory knew
> the names of the files it was going to look up.

I'm not in favor of auto-discovery (other than via naming convention)
because it is quite unclear to the user what actually is happening
(and in what order etc). Rather, DdlUtils will provide a hook (API
call, Ant task property) that allows the user to override any
defaults.

> The subprotocol/JDBC drivers (currently static values) would be left off
> in this version of the MSSqlPlatform. These, it seemed to me, would be
> better suited to being loaded from the same factory and value object by
> the PlatformUtils class. That is, rather than hard-coded, they would be
> discovered, allowing any person to substitute whatever crazy driver they
> had thought of (my first candidate, using SQL Server, was the jTDS
> driver, which I frequently use). Hopefully, this would make it possible
> (I haven't finished looking into this yet, however) for DdlUtils to
> recognize more drivers and handle them automatically and correctly.

There won't be any auto-discovery and -configuration of JDBC drivers
simply because there is no standard way to access the info that
DdlUtils needs, via plain JDBC. Rather, every driver (possibly even
for different driver versions), we need to come up with driver and
database-version specific code to get the info from the database. This
is not so much an issue when creating a database from XML but rather
when creating XML for a live database or dumping data as XML from one.

> I only foresee changes in those classes that have hard-coded information
> currently (and of course you can't make them configurable without a
> change, by definition). Possibly one or two refactorings might affect
> the functionality of base classes transparently. Most of what I would
> propose would be entirely new classes that only interact with the
> current classes within encapsulation.

Well, actually I don't see a strong use case for making these
hard-coded things configurable in this way. The problem is that
creating databases is easy (and easily configurable), but reading back
a live database is not. There'll always be workarounds, SQL queries to
get certain information, etc. And these cannot be configured but have
to be coded.

> Obviously, an entirely different line of thought might be devoted to
> making the tool sufficiently generic not to even have to know about
> specific databases at all (in other words, all the information required
> to make the tool work correctly would be in configuration information).
> That's far more ambitious than I am suggesting here, if it's even
> possible. However, it may be that this proposal is a small step in that
> direction.

As I said above, this won't be possible. And after all DdlUtils is
intended to provide this generic layer to other apps (via the API).\
Of course, it is certainly possible to make it easier to add
configurations (DB/DB version, JDBC driver, perhaps OS), but we cannot
make it generic.

cheers,
Tom

Mime
View raw message