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 Thu, 28 Sep 2006 21:54:50 GMT
Sure - I understand you'll have to restrict Abator to a specific schema -
but my enhancement would allow you to tell Abator not to include the schema
in its generated SQL.

I think the way to deal with synonyms would be to generate against the table
the synonym pointed to - but make abator write the code to interact with the
synonym rather than the specific table.  This would also be possible with my
proposed enhancement.  So if you have synonym FRED pointing to HR.EMPLOYEES,
you could generate against HR.EMPLOYEES, but have abator write the SQL to

Are you using the eclipse plugin or plain abator?  If you're using plain
abator, then I'll get something committed in a day or two and you could try

Jeff Butler

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