> On that same topic, if there are interfaces that we want to expose, and > implementations of the interfaces that are typically hidden, we need > factories that can produce the implementation classes. This leads to a > bootstrap issue: how to instantiate a factory. > > There are several options that we've used to solve the factory > bootstrap issue, and once we make a decision on the interfaces, the > factories are the next step toward a solution. > > The solution that we choose will affect the interfaces as well. I'm > comfortable with a pattern in which the interface for Table for example > includes a factory method for Column. So once you have solved the top > level bootstrap issue, you have factories for all the subordinate > interfaces built into the interfaces themselves.
I'd like to avoid having the element creation in the implementation. Rather I'd prefer a model factory that can create the 8 model element types. For reading a model from a database/XML file, the registration is not a problem. You simply register the factory at the reader object. For creating a model manually, you probably don't need a factory anyway and rather use the model objects themselves. > Another issue I'd like to talk about is the handling of Catalog and > Schema. It appears that in a Database, you can have Tables that are of > different catalogs and schema, but when you find a Table in a database, > you ignore the catalog and schema. Is it possible to have a Database > with two tables with the same name but different catalogs and schema? > Or will that result in a name clash? I don't know off-hand how that is handled (as I said, unit tests are missing), but I'd like to think that this depends upon the jdbc driver. For DdlUtils it is no problem that the table name has a dot in it (i.e. something like a qualified name), but the question is in what form the jdbc driver returns metadata for databases that support catalogs/schemas. Which databases support these ? Tom
