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.
-----Original Message-----
From: Jeff Butler [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 28, 2006 11:02 AM
To: dev@ibatis.apache.org
Subject: Re: Abator introspection patchNever mind - I installed Oracle myself and did some testing. Here's what I found...getColumns() won't return data from synonyms unless the "includeSynonyms" property is set to true on the DB connection. Even then, getColumns() will return the schema of the target table. For example, I created a public synonym "FRED" for " HR.EMPLOYEES". getColumns() returns the columns as if they are in table "HR.FRED".This means that you can use abator AS IS to generate objects from synonyms. Set the property "includeSynonyms" to "true" on the abator connection configuration, specify the synonym as the table name, and don't include any schema information.But...no amount of coaxing will persuade Oracle to return primaryKey or index information from a table synonym, so the generated objects will likely be incomplete (BTW - the "select *" method doesn't help here either).Bottom line - generating objects from Oracle synonyms is problematical at best.One thing that would help (and would be a good addition to abator) is the ability to ignore the schema qualifier in generated objects and change the table name. I'm thinking this:<table tableName="EMPLOYEES" schema="HR"><property name="ignoreQualifiers" value="true"/><property name="tableSynonym" value="FRED"/></table>This would generate objects based on HR.EMPLOYEES, but the SQL would write queries to FRED.Thoughts???Jeff Butler
On 9/28/06, [EMAIL PROTECTED] <[EMAIL PROTECTED] > wrote:I'll have to experiment some more with the JDBC metadata APIs to find out how they respond. I'll see if I can get to that this afternoon.
