Whoops. I jumped the gun. There is no difference observed regardless of the
order in which the primary key fields are listed in the orion-ejb-jar.xml
contained in the EAR. In fact, when Orion generates the full
orion-ejb-jar.xml it ignores the order in the provided orion-ejb-jar.xml,
and imposes its own ordering. The original problem remains.
Our ugly workaround is to eliminate the Catalog field in CatalogEntry and
instead have a field for each of the composite PK fields of Catalog. This
way, they can be specified individually in the finder queries, preventing
Orion from screwing up the order of insertion in the finder code.
P.Pontbriand
Canlink Interactive Technologies Inc.
----- Original Message -----
From: "Peter Pontbriand" <[EMAIL PROTECTED]>
To: "Orion-Interest" <[EMAIL PROTECTED]>
Sent: Wednesday, April 04, 2001 10:56 AM
Subject: Re: Collection Finders With Entity Argument Always Return Empty
Collection
> Your second suggestion's on the money. Although the <primkey-mapping>
block
> for CatalogEJB used our standard listing of identity first and then
locale,
> the orion-ejb-jar.xml had locale first and then identity in the
> cmp-field-mapping for CatalogEntryEJB's Catalog field. Reversing this
causes
> the generated finder code to correctly insert the SQL parameters.
>
> Its too bad that the orion-ejb-jar.xml was not generated correctly the
first
> time, but manually ensuring that the order of the primary key fields
matches
> throughout the deployment descriptors does seem to resolve the problem.
>
> P.Pontbriand
> Canlink Interactive Technologies Inc.
>
> ----- Original Message -----
> From: "Jeff Schnitzer" <[EMAIL PROTECTED]>
> To: "Orion-Interest" <[EMAIL PROTECTED]>
> Sent: Tuesday, April 03, 2001 7:32 PM
> Subject: RE: Collection Finders With Entity Argument Always Return Empty
> Collection
>
>
> > Try reversing the order of the fields in the <primkey-mapping> block for
> > the bean in the orion-ejb-jar.xml. Might also work just to change the
> > order in the ejb-jar.xml, especially if you deploy from scratch.
> >
> > Jeff
> >
> > >-----Original Message-----
> > >From: Peter Pontbriand [mailto:[EMAIL PROTECTED]]
> > >Sent: Wednesday, March 28, 2001 7:51 AM
> > >To: Orion-Interest
> > >Subject: Re: Collection Finders With Entity Argument Always
> > >Return Empty
> > >Collection
> > >
> > >
> > >Hmm. it seems a good under-desk gibbering session is helps
> > >focus the brain.
> > >Once that was over with, I copied the generated finder code
> > >(below) into an
> > >EJB of my own and executed it, getting the same results - not
> > >rows in the
> > >ResultSet. I then wasted a whack of time trying to lay my
> > >eyeballs on the
> > >actual final SQL statement being tossed at the database. No
> > >luck there, no
> > >amount of downcasting to assorted Oracle JDBC Driver Statement
> > >classes would
> > >produce a way to get a human readable parameterized SQL statement. No
> > >matter, though, since by chance I spotted the problem in the
> > >generated code:
> > >
> > >THE ORION-GENERATED CODE REVERSES THE ORDER OF THE STATEMENT
> > >PARAMETERS!!!
> > >
> > >Notice the criteria in the where clause: first is
> > >CatalogEntryEJB.catalogIdentity, second is
> > >CatalogEntryEJB.catalogLocale.
> > >These are the two fields of the composite primary key of CatalogEJB, a
> > >String and a Locale respectively.
> > >
> > >Now look at the code that inserts the values for these parameters:
> > >
> > >First is: statement.setString(1,
> > >com.evermind.util.ObjectUtils.toString(primaryKey398.locale));
> > >And second is: statement.setString(2, primaryKey398.identity);
> > >
> > >The locale is being inserted where the identity should be, and
> > >vice-versa.
> > >
> > >Bugzilla Bug #379 has been posted. Anybody got a
> > >non-stomach-churningly-ugly
> > >workaround idea?
> > >
> > >P. Pontbriand
> > >Canlink Interactive Technologies, Inc.
> > >
>
>
>
>
