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 Sat, 07 Oct 2006 02:48:17 GMT
On 10/6/06, David Sills <DSills@datasourceinc.com> wrote:

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

Well, I tend to use additional (external) files only if they provide
benefits. In the case of DdlUtils, such XML files cannot contain all
that is required to do the type mapping, so this would only spread the
type mapping to code *and* XML files which I dislike only for this
very reason.

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

Yep, the whole type mapping thing might look different after
implementing these features and then might be easier (or harder) to
make configurable.

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

No, the thing is that this is info specific to this platform, so I
would expect it to be defined somewhere within the platform, not
somewhere else (principle of least surprise).
Ideally, one would like some form of discovery/registration of the
platforms, but this usually involves either an (external)
configuration (e.g. via Spring) or some classpath magic, both of which
have their own problems.
However, a mixture between a registration API and static platform
configuration (in the sense that the currently defined platforms are
fixed and known at compile time, so their registration can be done in
code rather than via auto-discovery) should be doable.

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

No problem at all. Asking such questions is always a good way to learn
something, and it forces us developers to (re-)think decisions that we
made or are about to make.


View raw message