On 10/5/06, David Sills <[EMAIL PROTECTED]> wrote:
<snip>
You will note that comparison with the current MSSqlPlatform class makes it perfectly clear that these are simply equivalents with XML markup. (I haven't been through every Platform implementation yet, so this is still subject to minor amendments, of course).
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.
You will note that I left the manner of obtaining this value object unspecified above. My idea was to have a singleton factory that statically loaded all the XML files it could find at runtime (it might know about them, do Java discovery to get a list to look up, or simply find them by a naming convention). It would be my idea, as you can see, to acquire the XML files as classpath resources, so as to make it simple for anyone to substitute for any of the files they like by simply putting their replacements earlier on the classpath. This would probably be made easiest (though it's a little restrictive) if the factory knew the names of the files it was going to look up.
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 defaults.
The subprotocol/JDBC drivers (currently static values) would be left off in this version of the MSSqlPlatform. These, it seemed to me, would be better suited to being loaded from the same factory and value object by the PlatformUtils class. That is, rather than hard-coded, they would be discovered, allowing any person to substitute whatever crazy driver they had thought of (my first candidate, using SQL Server, was the jTDS driver, which I frequently use). Hopefully, this would make it possible (I haven't finished looking into this yet, however) for DdlUtils to recognize more drivers and handle them automatically and correctly.
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 only foresee changes in those classes that have hard-coded information currently (and of course you can't make them configurable without a change, by definition). Possibly one or two refactorings might affect the functionality of base classes transparently. Most of what I would propose would be entirely new classes that only interact with the current classes within encapsulation.
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.
Obviously, an entirely different line of thought might be devoted to making the tool sufficiently generic not to even have to know about specific databases at all (in other words, all the information required to make the tool work correctly would be in configuration information). That's far more ambitious than I am suggesting here, if it's even possible. However, it may be that this proposal is a small step in that direction.
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. cheers, Tom
