Re: Collection Finders With Entity Argument Always Return Empty Collection

2001-04-04 Thread Peter Pontbriand

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.
 






Re: Collection Finders With Entity Argument Always Return Empty Collection

2001-04-04 Thread Peter Pontbriand

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.
  









RE: Collection Finders With Entity Argument Always Return Empty Collection

2001-04-03 Thread Jeff Schnitzer

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.


- Original Message -
From: "Peter Pontbriand" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Tuesday, March 27, 2001 12:27 PM
Subject: Collection Finders With Entity Argument Always Return Empty
Collection


 
 java.sql.PreparedStatement statement =
connection.getCustomStatement("select
 CatalogEntryEJB.identity, CatalogEntryEJB.catalogIdentity,
 CatalogEntryEJB.catalogLocale, CatalogEntryEJB.label,
 CatalogEntryEJB.targetRoleIdentity, 
CatalogEntryEJB.referenceidentity,
 CatalogEntryEJB.price, CatalogEntryEJB.discountRate,
 CatalogEntryEJB.parentreferenceidentity, 
CatalogEntryEJB.referenceTypeInt,
 CatalogEntryEJB.productCode, CatalogEntryEJB.description,
 CatalogEntryEJB.extendedDescription, CatalogEntryEJB.listIndex,
 CatalogEntryEJB.created, CatalogEntryEJB.creator,
CatalogEntryEJB.modified,
 CatalogEntryEJB.modifier from CatalogEntryEJB where
 CatalogEntryEJB.catalogIdentity = ? and 
CatalogEntryEJB.catalogLocale =
?");
 try {
 com.canlink.components.base.LocalizedEntityPK primaryKey398 =
 argument0 == null ? null :
 ((com.canlink.components.base.LocalizedEntityPK)
 argument0.getPrimaryKey());
 {
 if (primaryKey398 == null) {
 if (((java.util.Locale) null) == null) 
statement.setNull(1,
 java.sql.Types.VARCHAR);
 else
 statement.setString(1,

 com.evermind.util.ObjectUtils.toString(((java.util.Locale) null)));
 if (((java.lang.String) null) == null) 
statement.setNull(2,
 java.sql.Types.VARCHAR);
 else
 statement.setString(2, ((java.lang.String) null));
 }
 else {
 if (primaryKey398.locale == null) statement.setNull(1,
 java.sql.Types.VARCHAR);
 else
 statement.setString(1,

 com.evermind.util.ObjectUtils.toString(primaryKey398.locale));
 if (primaryKey398.identity == null) statement.setNull(2,
 java.sql.Types.VARCHAR);
 else
 statement.setString(2, primaryKey398.identity);
 }
 }
 }
 finally {
 }
 java.sql.ResultSet set = statement.executeQuery();
 while (set.next()) {
 
 }