db-ddlutils-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Sills" <DSi...@datasourceinc.com>
Subject RE: Some ideas for dynamic configuration of Platform implementations
Date Fri, 06 Oct 2006 22:10:37 GMT

Thanks for your careful and considered reply. I do have a few responses.
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.

I looked at the Oracle case just prior to receiving your note, by
chance, and see exactly what you mean. Perhaps we can encapsulate the
backmapping logic in a Strategy object and let the user replace it by
configuration if they want to? After all, the logic for Oracle at least
is quite complex, but it's localized. And writing alternative strategies
is something that should be fairly straightforward, if not necessarily
easy, and also that ought to be rare enough.

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

I agree that naming convention is probably most useful here. What I'm
thinking about after this discussion is that, although I still like the
idea of a default XML (since it's at least somewhat self-explanatory,
which code is decidedly not), it's not an important idea (incidentally,
I got it working this morning, and so far it does appear to be a drop-in
replacement as far as initialization goes, though obviously it doesn't
deal with the column-by-column type-mapping issues of Oracle).
Hard-coding is just as practical, if practicality is the only end in
view (I often put consistency and clarity on just as high a footing, but
that's just me). However, with either API calls or Ant task properties
to override defaults, I would still like to be able to point to a file
that contains all the changes I'd want to make in one discreet location,
if only because I could avoid having to replace type-mappings one by one
when using the tool programmatically, or having to litter my Ant file
with them (I already don't like what one has to do with the Javadoc task
in way too many cases). Any issue there?

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 take this point quite readily. I have done something not dissimilar to
the reading from a database schema in another context, and you should
have seen some of the workarounds for the limitations of JDBC and the
bugs in many of the drivers. OK, that was a utopian idea that should
probably be abandoned. However, it would seem to make it harder to
maintain the software when there are driver constants and info in so
many places, PlatformInfo and all the Platform implementations. Mightn't
it be a step forward to at least put everything in a single place, from
which it can be cleanly changed with a view of the whole picture? For
instance, it took me a while to discover that some of the constants
aren't even used anywhere, and you saw that I wondered where my jTDS
driver had gone until I finally worked it out (from the comments!).

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.

I'm not quite sure which hard-coded things you're referring to here.
JDBC drivers, as I say, I think I see your point. Since everything has
to be specialized to the database and driver, there wouldn't be much
point in trying to configure JDBC drivers. Type-mappings are (it seems
to me) quite another kettle of fish. But I would be content with a
default mapping that I could override on a wholesale basis.

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.

Another utopian idea - I have lots of them. But I find that sometimes
things that might not have happened without them do in fact work out.

Before I come up with a list of action items, I'd appreciate very much
knowing your thoughts about some of these issues. I appreciate the time
and care you've already spent with the tool, and are spending now. It
has great potential, a good bit of which it has already attained.
Incidentally, if I can lend a hand with ideas you already have, please
let me know. You haven't mentioned much about the ideas you have
developed on the subject, and I'm obviously decidedly interested.

Best wishes,

View raw message