ibatis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Patrick.Higg...@cexp.com>
Subject RE: Abator introspection patch
Date Thu, 28 Sep 2006 21:40:12 GMT
We have to restrict the search at generation time to a specific schema so we don't pick up
definitions from other people's tables. If you do that, you don't see tables from other schemas,
even if there's a public synonym for that table. At least, that's the behavior I see with
the 10.2.0 driver against a database.
I do realize that we need to generate against a specific schema and run without one. That
capability would be very helpful. At present, I don't see any way to deal with the synonyms,
especially if keys on them can't be detected. We might need to code a special Oracle introspector
to look at the system views and apply the unqualified schema resolution rules. Ugh.

-----Original Message-----
From: Jeff Butler [mailto:jeffgbutler@gmail.com]
Sent: Thursday, September 28, 2006 3:32 PM
To: dev@ibatis.apache.org
Subject: Re: Abator introspection patch

Not so...FRED is a public synonym (not in any schema).  It's just Oracle JDBC wierdness with
synonyms.  I saw all kinds of wierd things in my testing.
Maybe you misunderstood my proposed fix...I'm proposing a way for you to GENERATE against
a specific schema, but RUN without any schema specified.  This means that the default schema
(or synonym) for the user would be used. 
I really think this would resolve the issue.  I'm not proposing that you change anything about
how your database is defined.
Jeff Butler

On 9/28/06, Patrick.Higgins@cexp.com < Patrick.Higgins@cexp.com > wrote: 

The includeSynonyms trick does not work with public synonyms for tables in other schemas.
Your example is just an alias for a table in the same schema (HR.EMPLOYEES and HR.FRED are
both in schema HR). We create synonyms only to reference tables in other schemas as though
they were in our schema. 
We might be able to get by without synonyms, but not specifying a schema will simply not work,
because we have 8 schemas that all have the same table names. Currently, Abator just uses
the first table it finds, which doesn't correspond to the user's default schema. We don't
want to hardcode the schema name into the abator configs because each developer uses a different
one. We might be able to use an entity reference to store these externally, but that brings
up another problem I found with Abator that may have already been addressed in SVN, but the
entity resolver throws an exception rather than returning null for entities it doesn't recognize,
so you can't define your own entities in the DOCTYPE. 


View raw message