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 22:37:22 GMT
On 10/6/06, David Sills <DSills@datasourceinc.com> wrote:

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

In fact, they are strategy classes: one for SQL generation (i.e. XMl
-> database) and one for reading of a live database (model reader),
both maintained by the platform object.

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

While I like declaring stuff (as opposed to e.g. put them in code),
there is the problem that I'm not sure that the type mappings can
remain a static as they are now, esp. when adding overrides in the
schema XML or via the Ant task. Also, I don't want to force somebody
using the API to have to write an XML file just to configure the
The point that I'm trying to make here is that such an XML
configuration file does add any value to the average user (because
he/she simply uses one of the platforms and that's it). But for folks
that add platforms or use the API in some unanticipated way, it might
just as easily complicate stuff more (e.g. one more file, not as
easily debuggable) etc.
So for now, I'd rather keep the mechanism and revisit this after the
local-mapping overrides are in place and perhaps some refactoring has
happened to make the mapping easier changeable via the API.

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

Actually right now all the info about a specific db-driver combo is in
one place (by design) which happens to be the platform directory. And
within that directory the info is spread over the 3 files in logical
way (who needs what info).

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

I'm kind of wondering why you want to override them "on a wholesale
basis" as you say. Why not simply create a new platform (on the fly if
necessary) ? This would perhaps even reduce the amount of typing (only
redefine what needs changing).

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

The general idea is to start with the three-levels of type mapping

* override for an Ant task run (which equals to a API usage session)
* override for a particular schema
* override for a particular table and/or column

The last two require that the migration to XML schema for the database
schema files is finished.
This also has to be in sync with the native type support (e.g. reading
back native type info and storing it into the schema XML generated by
DdlUtils from a live database), and with the unicode support (e.g.

The steps then inolve:

* define use cases and examples (-> unit tests)
* define how this would be expressed in the schema file and/or Ant task
* implement it

Implementing should then be doable in smaller steps, e.g. starting
with adding reading and storing native type info from the live
database, add ability to override the type mapping on a per-column
basis, ...


View raw message