Some questions...
How does the actual table get selected at run time? Is there a default schema specified on the db connection? Or, are the aliases not in a schema and there is some way to switch the aliases to the proper schema at runtime?
Do you actually want to generate the artifacts based on a specific schema, but just not include the schema in the generated XML?
Seems like it would be much easier to give you the option to generate against a specific schema, but then not include the schema in the generated code.
Jeff Butler
On 9/27/06, [EMAIL PROTECTED] <
[EMAIL PROTECTED] > wrote:
I've had trouble with Abator's interaction with Oracle schemas. I've implemented and attached a patch to the DatabaseIntrospector that refactors it into a choice of using the DatabaseMetaData API and the ResultSetMetaData API to get information about a table.
The problem is that we have several schemas with the same tables as well as synonyms for a subset of these. Using DatabaseMetaData.getColumns(...) ends up returning data from an arbitrary schema, and in our case, it's never the one we want. The way to get around this is normally to specify a schema name in the config file, but we actually use different schemas in dev, test, and production. What we really want is the table that is found without any qualification.
The best way I know to do this is just run "select * from tablename" and let Oracle deal with the schema and synonym resolution, the examine the ResultSetMetaData. Luckily, the ResultSetMetaData gives all the information Abator actually uses from the DatabaseMetaData, so I've implemented this as a proof-of-concept.
I tried to refactor the code as little as possible, but it was not especially easy.
Let me know what you think. In particular, I'd like to know if we really need to support both techniques. Is there any case where the ResultSetMetaData approach would fail? Should it be the default? Can we remove the DatabaseMetaData.getColumns(...) code entirely?
--Patrick
