Tom: Thanks for your careful and considered reply. I do have a few responses. *********** 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. ***********
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. *********** 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. *********** 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? *********** 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 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!). *********** 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. *********** 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. *********** 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. *********** Another utopian idea - I have lots of them. But I find that sometimes things that might not have happened without them do in fact work out. 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. Best wishes, David
