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 Sat, 07 Oct 2006 00:36:28 GMT
Tom:

As for my preference for a file to put type-mapping overrides in one
place, that's just the result of many projects with data all over the
place. I like Betwixt and Digester and how they convert configuration
information into simple, self-explanatory XML files. I'm afraid I'm
missing your point about the difficulty of such files - in my experience
they are vastly easier to maintain than code. In particular, no
compilation to change configuration if there's a problem. I don't like
compilers much in terms of this sort of thing. Of course, your mileage
may vary, and pretty clearly has.

However, I certainly have no issue in any case with deferring this kind
of change until we've implemented something for single changes. If
nothing else, working on this has certainly taught me a good deal about
how an important part of the system works. Well worth it for that alone.

But I don't quite get your point about all the driver-DB info being in
the platform directory. PlatformInfo (not in the platform directory) is
coupled to many sub-packages (something I generally try hard to avoid -
coupling to parent packages is fine, but not downwards). And the only
function I can see of many of the constants in the Platform
implementations is to be used in PlatformInfo. Why not just put them in
PlatformInfo and be done with it? Or put them in a PlatformConstants
class and use them from there? The Platform implementations that carry
them don't actually use them (at least, time and again, when I comment
them out, only the PlatformInfo fails compilation). Spreading things out
does make it rather confusing for first-time users like me, as you have
already seen.

My $0.02. (I hope you will forgive my frankness in asking questions
where I don't understand and making my points where I have them. If
that's offensive, then I will be happy to take myself off the list and
will watch developments in this tool with great interest. I do listen
carefully, as I hope you have seen, and I hope it's clear that I can be
convinced.)

I will look at your steps forward and see how I might be helpful.

**********
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. NVARCHAR vs. VARCHAR)

The steps then involve:

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

What is the status of XML schema migration, and has it an ETA? This is
also something with which I have a lot of experience, and perhaps could
be of assistance. And is someone already working on the native type
storage? Perhaps I could help there, having done something rather like
it elsewhere. I have some schemas lying around that explicitly use all
the available database types (or all I knew about at the time, anyway).
Perhaps they could be helpful in unit tests. I'll see whether I can find
them.

Best wishes,
David


Mime
View raw message