ibatis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Butler" <jeffgbut...@gmail.com>
Subject Re: Abator introspection patch
Date Wed, 27 Sep 2006 20:29:46 GMT
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

Jeff Butler

On 9/27/06, Patrick.Higgins@cexp.com <Patrick.Higgins@cexp.com > 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

View raw message