RE: Abator introspection patch

[Patrick.Higgins]

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 9.2.0.6 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:[EMAIL PROTECTED]
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, [EMAIL PROTECTED] <[EMAIL PROTECTED] > 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.