On 10/6/06, David Sills <[EMAIL PROTECTED]> wrote:
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.
In fact, they are strategy classes: one for SQL generation (i.e. XMl -> database) and one for reading of a live database (model reader), both maintained by the platform object.
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?
While I like declaring stuff (as opposed to e.g. put them in code), there is the problem that I'm not sure that the type mappings can remain a static as they are now, esp. when adding overrides in the schema XML or via the Ant task. Also, I don't want to force somebody using the API to have to write an XML file just to configure the mapping. The point that I'm trying to make here is that such an XML configuration file does add any value to the average user (because he/she simply uses one of the platforms and that's it). But for folks that add platforms or use the API in some unanticipated way, it might just as easily complicate stuff more (e.g. one more file, not as easily debuggable) etc. So for now, I'd rather keep the mechanism and revisit this after the local-mapping overrides are in place and perhaps some refactoring has happened to make the mapping easier changeable via the API.
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!).
Actually right now all the info about a specific db-driver combo is in one place (by design) which happens to be the platform directory. And within that directory the info is spread over the 3 files in logical way (who needs what info).
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.
I'm kind of wondering why you want to override them "on a wholesale basis" as you say. Why not simply create a new platform (on the fly if necessary) ? This would perhaps even reduce the amount of typing (only redefine what needs changing).
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.
The general idea is to start with the three-levels of type mapping configuration: * override for an Ant task run (which equals to a API usage session) * override for a particular schema * override for a particular table and/or column 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 inolve: * 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, ... cheers Tom
