Return-Path: Delivered-To: apmail-ibatis-dev-archive@www.apache.org Received: (qmail 9648 invoked from network); 28 Sep 2006 21:54:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 28 Sep 2006 21:54:57 -0000 Received: (qmail 7643 invoked by uid 500); 28 Sep 2006 21:54:57 -0000 Delivered-To: apmail-ibatis-dev-archive@ibatis.apache.org Received: (qmail 7500 invoked by uid 500); 28 Sep 2006 21:54:57 -0000 Mailing-List: contact dev-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ibatis.apache.org Delivered-To: mailing list dev@ibatis.apache.org Received: (qmail 7489 invoked by uid 99); 28 Sep 2006 21:54:57 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Sep 2006 14:54:57 -0700 Authentication-Results: idunn.apache.osuosl.org header.from=jeffgbutler@gmail.com; domainkeys=good X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE DomainKey-Status: good X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 Received: from [66.249.82.228] ([66.249.82.228:3705] helo=wx-out-0506.google.com) by idunn.apache.osuosl.org (ecelerity 2.1.1.8 r(12930)) with ESMTP id ED/42-00212-DA44C154 for ; Thu, 28 Sep 2006 14:54:54 -0700 Received: by wx-out-0506.google.com with SMTP id h30so766564wxd for ; Thu, 28 Sep 2006 14:54:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=mT1ciX6eQ23LHcgazg6OakVzRq97IX2rCM8mi5kps1kYLlBzI5ZzT/Xv6kKUbMlxgg5HmIMkGqzpAf3wv2zdt1g0r3PEus0wnXDdzfNt6Oor3fw4E6PNn97Y2Wz8pu6Vv9v7dRXDnfhdvzyDbVZ0X3X+zQTyGMvywaKzLoqxpqQ= Received: by 10.90.103.2 with SMTP id a2mr1122229agc; Thu, 28 Sep 2006 14:54:50 -0700 (PDT) Received: by 10.90.118.17 with HTTP; Thu, 28 Sep 2006 14:54:50 -0700 (PDT) Message-ID: Date: Thu, 28 Sep 2006 16:54:50 -0500 From: "Jeff Butler" To: dev@ibatis.apache.org Subject: Re: Abator introspection patch In-Reply-To: <446CAC4FA9FEF14FB0F3E7A507769EB008F8EE47@USCOBRMFA-SE-70.northamerica.cexp.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_23264_14679386.1159480490605" References: <446CAC4FA9FEF14FB0F3E7A507769EB008F8EE47@USCOBRMFA-SE-70.northamerica.cexp.com> X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_23264_14679386.1159480490605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 FRED. 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 it. Jeff Butler On 9/28/06, 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 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: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 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. > > > > > > > > > > ------=_Part_23264_14679386.1159480490605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
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 FRED.
 
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 it.
 
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 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: 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.

 

------=_Part_23264_14679386.1159480490605--