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.
> >
