Re: @IdClass annotation for id field of type byte[]

2007-01-03 Thread Marc Prud'hommeaux


Can you file a JIRA report for the time being? Nothing immediately  
suspicious jumps out at me in the stack trace, but I am still fairly  
confident that this has something to do with our special blob  
handling in Oracle.





On Jan 3, 2007, at 10:14 AM, Kevin Sutter wrote:


Marc,
Supposedly, this problem is only happening on Oracle.  It's working  
just fine with DB2 and Derby.  This is a bit long, but here's the  
call stack for the problem...  I have also attached the java files  
for the ManagedEntity, Guid, and Agent classes.


1500  TRACE  [main] openjpa.MetaData - Resolving field  
[EMAIL PROTECTED].
4|true|0.0.0 org.apache.openjpa.persistence.ArgumentException :  
Errors encountered while resolving metadata.  See nested exceptions  
for details.
at org.apache.openjpa.meta.MetaDataRepository.resolve 
(MetaDataRepository.java:501)
at org.apache.openjpa.meta.MetaDataRepository.getMetaData  
(MetaDataRepository.java:283)
at org.apache.openjpa.meta.MetaDataRepository.getMetaData 
(MetaDataRepository.java:338)
at  
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData( 
JPQLExpressionBuilder.java :151)
at  
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaD 
ata(JPQLExpressionBuilder.java:131)
at  
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaD 
ata(JPQLExpressionBuilder.java :211)
at  
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaD 
ata(JPQLExpressionBuilder.java:181)
at  
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType( 
JPQLExpressionBuilder.java :174)
at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$1 
(JPQLExpressionBuilder.java:173)
at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder 
$ParsedJPQL.populate(JPQLExpressionBuilder.java:1658)
at org.apache.openjpa.kernel.jpql.JPQLParser.populate 
(JPQLParser.java:52)
at  
org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation 
(ExpressionStoreQuery.java:145)
at org.apache.openjpa.kernel.QueryImpl.newCompilation  
(QueryImpl.java:642)
at org.apache.openjpa.kernel.QueryImpl.compilationFromCache 
(QueryImpl.java:623)
at org.apache.openjpa.kernel.QueryImpl.compileForCompilation 
(QueryImpl.java:589)
at org.apache.openjpa.kernel.QueryImpl.compileForExecutor  
(QueryImpl.java:651)
at org.apache.openjpa.kernel.QueryImpl.getOperation 
(QueryImpl.java:1464)
at org.apache.openjpa.kernel.DelegatingQuery.getOperation 
(DelegatingQuery.java:120)
at org.apache.openjpa.persistence.QueryImpl.execute  
(QueryImpl.java:202)
at org.apache.openjpa.persistence.QueryImpl.getResultList 
(QueryImpl.java:251)

at jpa.test.LoadTestCase.testLoadAgents(LoadTestCase.java:30)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected (TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at  
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests 
(RemoteTestRunner.java :478)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run 
(RemoteTestRunner.java:344)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main 
(RemoteTestRunner.java:196)
Caused by: 4|true|0.0.0  
org.apache.openjpa.persistence.ArgumentException: You cannot join  
on column MNGD_ELEMENT.ME_GUID.  It is not managed by a mapping  
that supports joins.
at org.apache.openjpa.jdbc.meta.ClassMapping.assertJoinable  
(ClassMapping.java:235)
at org.apache.openjpa.jdbc.meta.strats.VerticalClassStrategy.map 
(VerticalClassStrategy.java:99)
at org.apache.openjpa.jdbc.meta.ClassMapping.setStrategy 
(ClassMapping.java:343)
at  
org.apache.openjpa.jdbc.meta.RuntimeStrategyInstaller.installStrategy( 
RuntimeStrategyInstaller.java:52)
at org.apache.openjpa.jdbc.meta.MappingRepository.prepareMapping 
(MappingRepository.java:305)
at org.apache.openjpa.meta.MetaDataRepository.preMapping  
(MetaDataRepository.java:600)
at org.apache.openjpa.meta.MetaDataRepository.resolve 
(MetaDataRepository.java:487)

... 33 more
NestedThrowables:
4|true|0.0.0 org.apache.openjpa.persistence.ArgumentException :  
You cannot join on column MNGD_ELEMENT.ME_GUID.  It is not  
managed by a mapping that supports joins.
at org.apache.openjpa.jdbc.meta.ClassMapping.assertJoinable 
(ClassMapping.java:235)
at  
org.apache.openjpa.jdbc.meta.strats.VerticalClassStrategy.map  
(VerticalClassStrategy.java:99)
at 

Re: @IdClass annotation for id field of type byte[]

2007-01-02 Thread Marc Prud'hommeaux

Kevin-

Also, this exception is supposedly only being produced with Oracle,  
not

DB2.  (I have not been able to verify that yet.)  This would seem to
indicate that it's dictionary-specific, but I'm not seeing anything  
there

yet...


Does Oracle even support blob primary keys? My recollection is that  
it didn't...


I suspect that the problem might be that since Oracle has a number of  
problems with in-line blobs in statements, we frequently issue a  
separate statement to load and store blobs from and to rows, but if  
it is the primary key, then we might be conflicting with that. Can  
you post the complete stack trace?





On Jan 2, 2007, at 6:03 PM, Kevin Sutter wrote:


Hi,
Some experimenting with the @IdClass support is producing a strange
exception message when attempting to map an id field of type byte[].
According to the OpenJPA documentation, we need to use an Identity  
Class to

use byte[] as the id field type.  Something like this:

@Entity
@IdClass (jpa.classes.Guid.class)
@Table(name=AGENT, schema=CDB)
public class Agent {

   @Id
   @Column(name=ME_GUID)
   private byte[] guid;
...

The Guid class has also been created with a single instance  
variable of type

byte[]:

public class Guid implements Serializable {
   private byte[] guid;
...

But, during the loading of the database, I am getting the following  
error...


org.apache.openjpa.util.MetaDataException: You cannot join on column 
AGENT.ME_GUID.  It is not managed by a mapping that supports joins

First off, the exception is confusing since I don't believe I am  
attempting

to do a join.  The guid column is in the same table as the Agent.

Also, this exception is supposedly only being produced with Oracle,  
not

DB2.  (I have not been able to verify that yet.)  This would seem to
indicate that it's dictionary-specific, but I'm not seeing anything  
there

yet...

I am in the process of validating the problem, but I thought I  
would drop a

line to the team to see if it rings any bells...

Thanks,
Kevin




Re: @IdClass annotation for id field of type byte[]

2007-01-02 Thread Dain Sundstrom
Can you have java field of type byte[] that maps to a NUMERIC (or  
heck a varchar) in he db?  I'm guessing that Kevin's guid is a fixed  
128 bit number.  If it is and he can map it to a non-blob type, it  
should be possible to join with any database system.


-dain

On Jan 2, 2007, at 3:09 PM, Marc Prud'hommeaux wrote:


Kevin-

Also, this exception is supposedly only being produced with  
Oracle, not

DB2.  (I have not been able to verify that yet.)  This would seem to
indicate that it's dictionary-specific, but I'm not seeing  
anything there

yet...


Does Oracle even support blob primary keys? My recollection is that  
it didn't...


I suspect that the problem might be that since Oracle has a number  
of problems with in-line blobs in statements, we frequently issue a  
separate statement to load and store blobs from and to rows, but if  
it is the primary key, then we might be conflicting with that. Can  
you post the complete stack trace?





On Jan 2, 2007, at 6:03 PM, Kevin Sutter wrote:


Hi,
Some experimenting with the @IdClass support is producing a strange
exception message when attempting to map an id field of type byte[].
According to the OpenJPA documentation, we need to use an Identity  
Class to

use byte[] as the id field type.  Something like this:

@Entity
@IdClass (jpa.classes.Guid.class)
@Table(name=AGENT, schema=CDB)
public class Agent {

   @Id
   @Column(name=ME_GUID)
   private byte[] guid;
...

The Guid class has also been created with a single instance  
variable of type

byte[]:

public class Guid implements Serializable {
   private byte[] guid;
...

But, during the loading of the database, I am getting the  
following error...


org.apache.openjpa.util.MetaDataException: You cannot join on  
column 

AGENT.ME_GUID.  It is not managed by a mapping that supports joins

First off, the exception is confusing since I don't believe I am  
attempting

to do a join.  The guid column is in the same table as the Agent.

Also, this exception is supposedly only being produced with  
Oracle, not

DB2.  (I have not been able to verify that yet.)  This would seem to
indicate that it's dictionary-specific, but I'm not seeing  
anything there

yet...

I am in the process of validating the problem, but I thought I  
would drop a

line to the team to see if it rings any bells...

Thanks,
Kevin




Re: @IdClass annotation for id field of type byte[]

2007-01-02 Thread Igor Fedorenko
You can use use RAW(16) to store GUIDs in Oracle. This datatype is 
allowed in primary keys.


--
Regards,
Igor

Dain Sundstrom wrote:
Can you have java field of type byte[] that maps to a NUMERIC (or heck a 
varchar) in he db?  I'm guessing that Kevin's guid is a fixed 128 bit 
number.  If it is and he can map it to a non-blob type, it should be 
possible to join with any database system.


-dain

On Jan 2, 2007, at 3:09 PM, Marc Prud'hommeaux wrote:


Kevin-


Also, this exception is supposedly only being produced with Oracle, not
DB2.  (I have not been able to verify that yet.)  This would seem to
indicate that it's dictionary-specific, but I'm not seeing anything 
there

yet...


Does Oracle even support blob primary keys? My recollection is that it 
didn't...


I suspect that the problem might be that since Oracle has a number of 
problems with in-line blobs in statements, we frequently issue a 
separate statement to load and store blobs from and to rows, but if it 
is the primary key, then we might be conflicting with that. Can you 
post the complete stack trace?





On Jan 2, 2007, at 6:03 PM, Kevin Sutter wrote:


Hi,
Some experimenting with the @IdClass support is producing a strange
exception message when attempting to map an id field of type byte[].
According to the OpenJPA documentation, we need to use an Identity 
Class to

use byte[] as the id field type.  Something like this:

@Entity
@IdClass (jpa.classes.Guid.class)
@Table(name=AGENT, schema=CDB)
public class Agent {

   @Id
   @Column(name=ME_GUID)
   private byte[] guid;
...

The Guid class has also been created with a single instance variable 
of type

byte[]:

public class Guid implements Serializable {
   private byte[] guid;
...

But, during the loading of the database, I am getting the following 
error...


org.apache.openjpa.util.MetaDataException: You cannot join on column 
AGENT.ME_GUID.  It is not managed by a mapping that supports joins

First off, the exception is confusing since I don't believe I am 
attempting

to do a join.  The guid column is in the same table as the Agent.

Also, this exception is supposedly only being produced with Oracle, not
DB2.  (I have not been able to verify that yet.)  This would seem to
indicate that it's dictionary-specific, but I'm not seeing anything 
there

yet...

I am in the process of validating the problem, but I thought I would 
drop a

line to the team to see if it rings any bells...

Thanks,
Kevin







Re: @IdClass annotation for id field of type byte[]

2007-01-02 Thread Marc Prud'hommeaux


Interesting ... sounds like a legit bug, then (although it bears  
noting that byte[] primary keys aren't actually allowed by the JPA  
spec, as per section 2.1.4 ... support for them is an OpenJPA  
extension).


My guess is that this only affects Oracle, due to our special  
handling of blobs. It'd be interesting to see if any other databases  
that support byte[] primary keys exhibit this problem.




On Jan 2, 2007, at 7:23 PM, Igor Fedorenko wrote:

You can use use RAW(16) to store GUIDs in Oracle. This datatype is  
allowed in primary keys.


--
Regards,
Igor

Dain Sundstrom wrote:
Can you have java field of type byte[] that maps to a NUMERIC (or  
heck a varchar) in he db?  I'm guessing that Kevin's guid is a  
fixed 128 bit number.  If it is and he can map it to a non-blob  
type, it should be possible to join with any database system.

-dain
On Jan 2, 2007, at 3:09 PM, Marc Prud'hommeaux wrote:

Kevin-

Also, this exception is supposedly only being produced with  
Oracle, not
DB2.  (I have not been able to verify that yet.)  This would  
seem to
indicate that it's dictionary-specific, but I'm not seeing  
anything there

yet...


Does Oracle even support blob primary keys? My recollection is  
that it didn't...


I suspect that the problem might be that since Oracle has a  
number of problems with in-line blobs in statements, we  
frequently issue a separate statement to load and store blobs  
from and to rows, but if it is the primary key, then we might be  
conflicting with that. Can you post the complete stack trace?





On Jan 2, 2007, at 6:03 PM, Kevin Sutter wrote:


Hi,
Some experimenting with the @IdClass support is producing a strange
exception message when attempting to map an id field of type byte 
[].
According to the OpenJPA documentation, we need to use an  
Identity Class to

use byte[] as the id field type.  Something like this:

@Entity
@IdClass (jpa.classes.Guid.class)
@Table(name=AGENT, schema=CDB)
public class Agent {

   @Id
   @Column(name=ME_GUID)
   private byte[] guid;
...

The Guid class has also been created with a single instance  
variable of type

byte[]:

public class Guid implements Serializable {
   private byte[] guid;
...

But, during the loading of the database, I am getting the  
following error...


org.apache.openjpa.util.MetaDataException: You cannot join on  
column 

AGENT.ME_GUID.  It is not managed by a mapping that supports joins

First off, the exception is confusing since I don't believe I am  
attempting

to do a join.  The guid column is in the same table as the Agent.

Also, this exception is supposedly only being produced with  
Oracle, not
DB2.  (I have not been able to verify that yet.)  This would  
seem to
indicate that it's dictionary-specific, but I'm not seeing  
anything there

yet...

I am in the process of validating the problem, but I thought I  
would drop a

line to the team to see if it rings any bells...

Thanks,
Kevin






RE: @IdClass annotation for id field of type byte[]

2007-01-02 Thread Patrick Linskey
You could do this with an @Externalizer that converts the byte[] into a
long or a string or what have you, and a @Factory that reverses it.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

 -Original Message-
 From: Dain Sundstrom [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, January 02, 2007 4:02 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: @IdClass annotation for id field of type byte[]
 
 Can you have java field of type byte[] that maps to a NUMERIC (or  
 heck a varchar) in he db?  I'm guessing that Kevin's guid is a fixed  
 128 bit number.  If it is and he can map it to a non-blob type, it  
 should be possible to join with any database system.
 
 -dain
 
 On Jan 2, 2007, at 3:09 PM, Marc Prud'hommeaux wrote:
 
  Kevin-
 
  Also, this exception is supposedly only being produced with  
  Oracle, not
  DB2.  (I have not been able to verify that yet.)  This 
 would seem to
  indicate that it's dictionary-specific, but I'm not seeing  
  anything there
  yet...
 
  Does Oracle even support blob primary keys? My recollection 
 is that  
  it didn't...
 
  I suspect that the problem might be that since Oracle has a number  
  of problems with in-line blobs in statements, we frequently 
 issue a  
  separate statement to load and store blobs from and to 
 rows, but if  
  it is the primary key, then we might be conflicting with that. Can  
  you post the complete stack trace?
 
 
 
 
  On Jan 2, 2007, at 6:03 PM, Kevin Sutter wrote:
 
  Hi,
  Some experimenting with the @IdClass support is producing a strange
  exception message when attempting to map an id field of 
 type byte[].
  According to the OpenJPA documentation, we need to use an 
 Identity  
  Class to
  use byte[] as the id field type.  Something like this:
 
  @Entity
  @IdClass (jpa.classes.Guid.class)
  @Table(name=AGENT, schema=CDB)
  public class Agent {
 
 @Id
 @Column(name=ME_GUID)
 private byte[] guid;
  ...
 
  The Guid class has also been created with a single instance  
  variable of type
  byte[]:
 
  public class Guid implements Serializable {
 private byte[] guid;
  ...
 
  But, during the loading of the database, I am getting the  
  following error...
 
  org.apache.openjpa.util.MetaDataException: You cannot join on  
  column 
  AGENT.ME_GUID.  It is not managed by a mapping that supports joins
 
  First off, the exception is confusing since I don't believe I am  
  attempting
  to do a join.  The guid column is in the same table as the Agent.
 
  Also, this exception is supposedly only being produced with  
  Oracle, not
  DB2.  (I have not been able to verify that yet.)  This 
 would seem to
  indicate that it's dictionary-specific, but I'm not seeing  
  anything there
  yet...
 
  I am in the process of validating the problem, but I thought I  
  would drop a
  line to the team to see if it rings any bells...
 
  Thanks,
  Kevin