On 10/6/06, David Sills <[EMAIL PROTECTED]> 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. cheers, Tom
