date:20070404

RE: Forced getter/setter access

2007-04-04 Thread Evan Ireland

Patrick,

I meant tuned as in not including columns in the SQL update set
clause if they weren't really changed by the app (even if a setter
was called, the old and new values may be the same).

The update set clause is 100% portable SQL.

So I'm not entirely clear what you mean by:

tuned for your implementation

 -Original Message-
 From: Patrick Linskey [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, 4 April 2007 5:44 p.m.
 To: open-jpa-dev@incubator.apache.org
 Subject: RE: Forced getter/setter access
 
  If you are going to issue tuned updates to the DB, 
 determining what 
  really changed (as opposed to what setter methods were
  called) can avoid unnecessary DB overheads.
 
 ... tuned for your implementation, that is. Often, business 
 needs require that a transaction involves a large number of 
 objects, and it would be unfortunate to have to compromise on 
 transaction integrity just for the sake of a particular 
 implementation. It's not just a matter of needing to 
 periodically call flush() during a tx, but rather of having 
 to design transactions that don't read too many objects.
 
 Happily, with OpenJPA, this is a non-issue, regardless of 
 property or field access.
 
 -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: Evan Ireland [mailto:[EMAIL PROTECTED]
  Sent: Tuesday, April 03, 2007 10:39 PM
  To: open-jpa-dev@incubator.apache.org
  Subject: RE: Forced getter/setter access
  
  Granted, but with a reasonable implementation the cost 
 should be low 
  for:
  
  at commit / flush time compare the current values with the 
 original 
  values to figure out what to write back to the database.
  
  If you are going to issue tuned updates to the DB, 
 determining what 
  really changed (as opposed to what setter methods were
  called) can avoid unnecessary DB overheads.
  
  Anyway at the end of the day, you must use the 
 getters/setters because 
  the spec says so, and you should write portable apps where possible 
  :-)
  
   -Original Message-
   From: Patrick Linskey [mailto:[EMAIL PROTECTED]
   Sent: Wednesday, 4 April 2007 5:21 p.m.
   To: open-jpa-dev@incubator.apache.org
   Subject: RE: Forced getter/setter access
   
   The main reason to support getter / setter access is for 
   implementations that cannot intercept field accesses. So, the 
   getters and setters are there so that the JPA implementation can 
   create a subclass of your entity type (hence the no-final-classes 
   rule) and track what happens as you invoke the setters 
 and getters. 
   In other words, your business methods become part of the JPA 
   implementation's domain.
   
   So, when using property access, your contract with the 
 JPA provider 
   is that you'll access persistent attributes only through 
 the setters 
   and getters, which allows the implementation to track what you do 
   and when you do it. If you could directly access the underlying 
   state, the implementation would have no way to know what happened 
   during the course of a transaction. This, in turn, would 
 mean that 
   the implementation would have to keep a copy of every bit of data 
   that you read during a transaction, and then at commit / 
 flush time 
   compare the current values with the original values to figure out 
   what to write back to the database.
   
   As it turns out, when you use OpenJPA, all your direct field 
   accesses are replaced with synthetic static methods 
 anyways, so from 
   a performance standpoint, you'll see equivalent behavior 
 either way. 
   In my experience, persistent domain model field access 
 performance 
   in tight loops is rarely actually a performance bottleneck; it's 
   almost always going back and forth to the database that ends up 
   being the bottleneck, and thus the most important place 
 to optimize.
   
   -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,

RE: Forced getter/setter access

2007-04-04 Thread Patrick Linskey

Ah... I was referring to the fact that if an implementation isn't
tracking field accesses, then it must sit around and do in-mem
comparisons (and hold onto hard refs to copies of all read data) in
order to figure out what to write back to the DB. So, I was referring
solely to the in-mem computation time, not to SQL generation.

-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: Evan Ireland [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, April 03, 2007 11:04 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: RE: Forced getter/setter access
 
 Patrick,
 
 I meant tuned as in not including columns in the SQL update set
 clause if they weren't really changed by the app (even if a setter
 was called, the old and new values may be the same).
 
 The update set clause is 100% portable SQL.
 
 So I'm not entirely clear what you mean by:
 
 tuned for your implementation
 
  -Original Message-
  From: Patrick Linskey [mailto:[EMAIL PROTECTED] 
  Sent: Wednesday, 4 April 2007 5:44 p.m.
  To: open-jpa-dev@incubator.apache.org
  Subject: RE: Forced getter/setter access
  
   If you are going to issue tuned updates to the DB, 
  determining what 
   really changed (as opposed to what setter methods were
   called) can avoid unnecessary DB overheads.
  
  ... tuned for your implementation, that is. Often, business 
  needs require that a transaction involves a large number of 
  objects, and it would be unfortunate to have to compromise on 
  transaction integrity just for the sake of a particular 
  implementation. It's not just a matter of needing to 
  periodically call flush() during a tx, but rather of having 
  to design transactions that don't read too many objects.
  
  Happily, with OpenJPA, this is a non-issue, regardless of 
  property or field access.
  
  -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: Evan Ireland [mailto:[EMAIL PROTECTED]
   Sent: Tuesday, April 03, 2007 10:39 PM
   To: open-jpa-dev@incubator.apache.org
   Subject: RE: Forced getter/setter access
   
   Granted, but with a reasonable implementation the cost 
  should be low 
   for:
   
   at commit / flush time compare the current values with the 
  original 
   values to figure out what to write back to the database.
   
   If you are going to issue tuned updates to the DB, 
  determining what 
   really changed (as opposed to what setter methods were
   called) can avoid unnecessary DB overheads.
   
   Anyway at the end of the day, you must use the 
  getters/setters because 
   the spec says so, and you should write portable apps 
 where possible 
   :-)
   
-Original Message-
From: Patrick Linskey [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 4 April 2007 5:21 p.m.
To: open-jpa-dev@incubator.apache.org
Subject: RE: Forced getter/setter access

The main reason to support getter / setter access is for 
implementations that cannot intercept field accesses. So, the 
getters and setters are there so that the JPA 
 implementation can 
create a subclass of your entity type (hence the 
 no-final-classes 
rule) and track what happens as you invoke the setters 
  and getters. 
In other words, your business methods become part of the JPA 
implementation's domain.

So, when using property access, your contract with the 
  JPA provider 
is that you'll access persistent attributes only through 
  the setters 
and getters, which allows the implementation to track 
 what you do 
and when you do it. If you could directly access the underlying 
state, the implementation would have no way to know 
 what happened 
during the course of a transaction. This, in turn, would 
  mean that 
the implementation would have to keep a copy of every 
 bit of data 
that you read during a transaction, and

Re: 0.9.8 release

2007-04-04 Thread robert burrell donkin


On 4/3/07, Michael Dick [EMAIL PROTECTED] wrote:

All too easy, thank you both!

 I just added the files. Release-notes and Changes came mostly from JIRA.


release notes are surprisingly important for open source projects.
downloads are often the first point of contact for potential users,
developers and downstream repackagers.  good release are a form of
geurilla advertising and conveying as good first impress of the
project.

IMHO it's better to think of the release notes in the broad: as
content which can and should be repeated in several different forms in
different locations. a release should be announced on the appropriate
mailing lists. downloaders are more likely the same content used for
the release notes . these notes also form the history of the project
and it's a good idea to record them permentantly on the website (this
is also useful for search engine indexes) with the date. the same
content can and should be used as a basis for all these notes.

i'd recommend starting with a sentence describing the nature of the
release (foo-1.2.3 is a bug fix release or foo-1.3.0 is a feature
release). then briefly outline compatibility (This release is
backwards compatible with foo-1.2.0.) then platform requirements
(Foo require Java 1.4.2 or higher).

the release notes should contain a paragraph introducing the project
and available resources (wesite, mailing lists and so). a sentence
encouraging people to get involved is also a good idea.

if the release is not backwards compatible with the last release, then
include a list of changes which those using earlier library need to
make. (use a tool to generate the base output.)

release notes don't need to be worked up every time from scratch: a
lot of this additional content will not change.

- robert

RE: Duplicate Query - where none exists

2007-04-04 Thread Phill Moran

I am using 0.9.6. I will see how to package this up so you can step through

  _  

From: Hans J. Prueller [mailto:[EMAIL PROTECTED] 
Sent: April 4, 2007 10:28 AM
To: open-jpa-dev@incubator.apache.org
Subject: RE: Duplicate Query - where none exists


I also encountered a similar problem with a 0.9.7 nightly snapshot:

when creating an EMF, openJPA brings up the message duplicate query
PositionLog.findById where definitiely
only a single named query of that name exists. As everything else works, I
didn't mind this message until now...

hans

Am Dienstag, den 03.04.2007, 22:23 -0700 schrieb Patrick Linskey: 

I haven't seen such a problem -- is it possible to package up the

problem in something that we can step through in a debugger / take a

closer look at?



-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: Phill Moran [mailto:[EMAIL PROTECTED] 

 Sent: Tuesday, April 03, 2007 10:07 PM

 To: open-jpa-dev@incubator.apache.org

 Subject: Duplicate Query - where none exists

 

 Anyone seen this before

 

 WARN   [main] openjpa.MetaData - Found duplicate query 

 StoreFXPK in class

 ..  Ignoring. 

 

 This class has only three such named queries all different 

 names and different

 actual queries. See following

 @NamedQueries( {

   @NamedQuery(name = StoreFXPK, query = SELECT 

 s FROM Store s

 WHERE s.id = :primaryKey),

   @NamedQuery(name = StoreFXTypeAndName, query 

 = SELECT s FROM

 Store s WHERE s.type = :type AND UPPER(s.name) LIKE :storeName OR

 UPPER(s.displayName) = :storeName2),

   @NamedQuery(name = StoreFXName, query = 

 SELECT s FROM Store s

 WHERE UPPER(s.name) = :storeName OR UPPER(s.displayName) = 

 :storeName2) 

   })

 

 I even renamed the duplicate parms to make sure it was not a 

 trickle down

 exception. Not only that, if I comment out the StoreFXPK 

 query I get the same

 error on the next named Query. I did a search on the 

 workspace an this is only

 used in one place (factory class) and define in another 

 (persistent class). I

 have no doubt this is something I have done but am unsure 

 what it is I get the

 follow stack trace when executing the following line:

 

 Query q = em.createNamedQuery(StoreFXName); - not the same 

 query mentioned in

 the above warning...the plot thickens

 

 The unmapped field in the stack trace is mapped.

 

 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(MetaDataRep

 ository.java:501)

   at

 org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDat

 aRepository.java:2

 83)

   at

 org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDat

 aRepository.java:3

 38)

   at

 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassM

 etaData(JPQLExpres

 sionBuilder.java:151)

   at

 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveCl

 assMetaData(JPQLEx

 pressionBuilder.java:131)

   at

 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandid

 ateMetaData(JPQLEx

 pressionBuilder.java:211)

   at

 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandid

 ateMetaData(JPQLEx

 pressionBuilder.java:181)

   at

 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandid

 ateType(JPQLExpres

 sionBuilder.java:174)

   at

 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$50

 0(JPQLExpressionBu

 ilder.java:61)

   at

 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQ

 L.populate(JPQLExp

 ressionBuilder.java:1657)

   at

 org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:52)

   at

 org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCom

 pilation(Expressio

 nStoreQuery.java:145)

   at

 org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:642)

   at

 org.apache.openjpa.kernel.QueryImpl.compilationFromCache(Query

 Impl.java:623)

   at

 org.apache.openjpa.kernel.QueryImpl.compileForCompilation(Quer

 yImpl.java:589)

   at

 org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryIm

 pl.java:651)

   at 

 org.apache.openjpa.kernel.QueryImpl.compile(QueryImpl.java:558)

   at

Re: why not an EntityExistsException was thrown?

2007-04-04 Thread Craig L Russell

If you look at the exception that is thrown from the database, it's a  
pretty general exception.


The statement was aborted because it would have caused a duplicate  
key  value in a unique or primary key constraint or unique index  
identified by  'SQL070403054930170' defined on 'BSC'.


This might have been caused by a unique constraint, which would not  
be properly reported as EntityExistsException.


Sadly, there is no standard SQL exception that specifically tells the  
provider (OpenJPA) that there was a primary key constraint violation.  
And you might also note that every database has its own way to report  
exceptions like this.


What the EntityExistsException does is to report that there is  
already an entity with the same primary key in the persistence  
context. It doesn't report that there was a problem writing the  
entity to the database.


If you're looking for better error reporting you can flush as part of  
the application-level persist operation. That way your application  
can catch a persistence exception that is caused either by persist or  
flush and report it as a problem persisting entity to your caller.


But there is a down side to this. If you flush immediately after  
persist, the provider cannot optimize for performance. So it's a  
tradeoff that you need to make in your application.


If you're keen on fixing this situation, I'd encourage you to  
volunteer to look at the databases and how they report unique and  
primary key constraint violations and see if it's possible to parse  
the sql code and report string to positively identify a primary key  
constraint violation.


Craig

On Apr 3, 2007, at 9:42 PM, wanyna wrote:



I can't find EntityExistsException nested in RollbackExceptions.
http://www.nabble.com/file/7646/exception.jpg

Will exception mechanism be planned to improve?
I think it's very important.


Patrick Linskey wrote:


Cool -- that explains it then.

EM.commit() must throw RollbackExceptions (and
org.apache.openjpa.persistence.RollbackException extends
javax.persistence.RollbackException) when the transaction is  
rolled back

during the course of the commit.

If you get the nested exception from the RollbackException, I bet  
that

it's instanceof EntityExistsException.

Clearly, however, something is wonky with our exception printing
algorithm.

-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: wanyna [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 03, 2007 8:49 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: why not an EntityExistsException was thrown?


actual class of the exception:
class org.apache.openjpa.persistence.RollbackException
2|true|0.9.7-incubating-SNAPSHOT
org.apache.openjpa.persistence.RollbackException: The
transaction has been
rolled back.  See the nested exceptions for details on the errors  
that

occurred.
at
org.apache.openjpa.persistence.EntityManagerImpl.commit(Entity
ManagerImpl.java:417)
at test.Main.main(Main.java:82)
Caused by: 0|true|0.9.7-incubating-SNAPSHOT
org.apache.openjpa.persistence.PersistenceException: The
transaction has
been rolled back.  See the nested exceptions for details on
the errors that
occurred.
at
org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerI
mpl.java:2091)
at
org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1938)
at
org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1836)
at
org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerIm
pl.java:1754)
at
org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalMana
gedRuntime.java:76)
at
org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1311)
at
org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBr
oker.java:863)
at
org.apache.openjpa.persistence.EntityManagerImpl.commit(Entity
ManagerImpl.java:406)
... 1 more
Caused by: 0|false|0.9.7-incubating-SNAPSHOT
org.apache.openjpa.persistence.PersistenceException: The  
statement was

aborted because it would have caused a duplicate key value in
a unique or
primary key constraint or unique index identified by
'SQL070403054930170'
defined on 'BSC'. {prepstmnt 15774883 INSERT INTO BSC (objid,  
objname,
created, msc_name, objclass) VALUES (?, ?, ?, ?, ?) [params= 
(long) 1,

(String) objname1, (Timestamp) 2006-05-04 18:13:51.0,
(String) objname0,
(String) bsc]} [code=-1, state=23505]

I am interested to join OPENJPA group

2007-04-04 Thread Kesara, Soma Sekhara Reddy

Hello 

 

I am interested to join OPENJPA group.

 

Regards

SomaSekharaReddy.K

 

Notice:  All email and instant messages (including attachments) sent to
or from Franklin Templeton Investments (FTI) personnel may be retained,
monitored and/or reviewed by FTI and its agents, or authorized
law enforcement personnel, without further notice or consent.

Re: why not an EntityExistsException was thrown?

2007-04-04 Thread robert burrell donkin


On 4/4/07, Craig L Russell [EMAIL PROTECTED] wrote:

If you look at the exception that is thrown from the database, it's a
pretty general exception.

The statement was aborted because it would have caused a duplicate
key  value in a unique or primary key constraint or unique index
identified by  'SQL070403054930170' defined on 'BSC'.

This might have been caused by a unique constraint, which would not
be properly reported as EntityExistsException.

Sadly, there is no standard SQL exception that specifically tells the
provider (OpenJPA) that there was a primary key constraint violation.
And you might also note that every database has its own way to report
exceptions like this.

What the EntityExistsException does is to report that there is
already an entity with the same primary key in the persistence
context. It doesn't report that there was a problem writing the
entity to the database.


snip


If you're keen on fixing this situation, I'd encourage you to
volunteer to look at the databases and how they report unique and
primary key constraint violations and see if it's possible to parse
the sql code and report string to positively identify a primary key
constraint violation.


an pluggable exception factory (in open-jpa) might make this approach
a little easier

- robert

Re: why not an EntityExistsException was thrown?

2007-04-04 Thread Abe White

 an pluggable exception factory (in open-jpa) might make this approach
 a little easier

See DBDictionary.newStoreException(...).

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.

RE: why not an EntityExistsException was thrown?

2007-04-04 Thread Patrick Linskey

 an pluggable exception factory (in open-jpa) might make this approach
 a little easier

To a certain extent, such a beast already exists -- see
DBDictionary.newStoreException(). We have special handling for HSQLDB
and JDataStore to add information about referential integrity constraint
types if the exception created is a ReferentialIntegrityException;
similar logic could be added for other databases.

The logic in DBDictionary.newStoreException() only knows that SQL code
23000 means referential integrity constraint of some sort.

-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: robert burrell donkin [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, April 04, 2007 9:57 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: why not an EntityExistsException was thrown?
 
 On 4/4/07, Craig L Russell [EMAIL PROTECTED] wrote:
  If you look at the exception that is thrown from the 
 database, it's a
  pretty general exception.
 
  The statement was aborted because it would have caused a duplicate
  key  value in a unique or primary key constraint or unique index
  identified by  'SQL070403054930170' defined on 'BSC'.
 
  This might have been caused by a unique constraint, which would not
  be properly reported as EntityExistsException.
 
  Sadly, there is no standard SQL exception that specifically 
 tells the
  provider (OpenJPA) that there was a primary key constraint 
 violation.
  And you might also note that every database has its own way 
 to report
  exceptions like this.
 
  What the EntityExistsException does is to report that there is
  already an entity with the same primary key in the persistence
  context. It doesn't report that there was a problem writing the
  entity to the database.
 
 snip
 
  If you're keen on fixing this situation, I'd encourage you to
  volunteer to look at the databases and how they report unique and
  primary key constraint violations and see if it's possible to parse
  the sql code and report string to positively identify a primary key
  constraint violation.
 
 an pluggable exception factory (in open-jpa) might make this approach
 a little easier
 
 - robert
 

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.

RE: I am interested to join OPENJPA group

2007-04-04 Thread Patrick Linskey

Hi,

Great! Are there any areas of the project that you are particularly
interested in working on? Are you more interested in doing development
work on the project, or are you more focused on using OpenJPA to build
applications?

Thanks,

-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: Kesara, Soma Sekhara Reddy [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, April 03, 2007 11:29 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: I am interested to join OPENJPA group
 
 Hello 
 
  
 
 I am interested to join OPENJPA group.
 
  
 
 Regards
 
 SomaSekharaReddy.K
 
  
 
 Notice:  All email and instant messages (including 
 attachments) sent to
 or from Franklin Templeton Investments (FTI) personnel may be 
 retained,
 monitored and/or reviewed by FTI and its agents, or authorized
 law enforcement personnel, without further notice or consent.
 

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.

Re: Duplicate Query - where none exists

2007-04-04 Thread Dain Sundstrom

I think I saw this once.  The problem is in JPA named queries are all  
contained in a single global namespace, so if you have to persistent  
beans that define queries with the same name you get a warning.  It  
would be nice if the warning told you where the duplicate  
declarations are located.


-dain

On Apr 3, 2007, at 10:07 PM, Phill Moran wrote:


Anyone seen this before

WARN   [main] openjpa.MetaData - Found duplicate query StoreFXPK  
in class

..  Ignoring.

This class has only three such named queries all different names  
and different

actual queries. See following
@NamedQueries( {
@NamedQuery(name = StoreFXPK, query = SELECT s FROM Store s
WHERE s.id = :primaryKey),
@NamedQuery(name = StoreFXTypeAndName, query = SELECT s FROM
Store s WHERE s.type = :type AND UPPER(s.name) LIKE :storeName OR
UPPER(s.displayName) = :storeName2),
@NamedQuery(name = StoreFXName, query = SELECT s FROM Store s
WHERE UPPER(s.name) = :storeName OR UPPER(s.displayName)  
= :storeName2)

})

I even renamed the duplicate parms to make sure it was not a  
trickle down
exception. Not only that, if I comment out the StoreFXPK query I  
get the same
error on the next named Query. I did a search on the workspace an  
this is only
used in one place (factory class) and define in another (persistent  
class). I
have no doubt this is something I have done but am unsure what it  
is I get the

follow stack trace when executing the following line:

Query q = em.createNamedQuery(StoreFXName); - not the same query  
mentioned in

the above warning...the plot thickens

The unmapped field in the stack trace is mapped.

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:2

83)
at
org.apache.openjpa.meta.MetaDataRepository.getMetaData 
(MetaDataRepository.java:3

38)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData( 
JPQLExpres

sionBuilder.java:151)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaD 
ata(JPQLEx

pressionBuilder.java:131)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaD 
ata(JPQLEx

pressionBuilder.java:211)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaD 
ata(JPQLEx

pressionBuilder.java:181)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType( 
JPQLExpres

sionBuilder.java:174)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$500 
(JPQLExpressionBu

ilder.java:61)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder 
$ParsedJPQL.populate(JPQLExp

ressionBuilder.java:1657)
at
org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:52)
at
org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation 
(Expressio

nStoreQuery.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.compile(QueryImpl.java:558)
at
org.apache.openjpa.persistence.EntityManagerImpl.createNamedQuery 
(EntityManagerI

mpl.java:699)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:39)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.jav

a:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.springframework.orm.jpa.ExtendedEntityManagerCreator 
$ExtendedEntityManagerIn

vocationHandler.invoke(ExtendedEntityManagerCreator.java:237)
at $Proxy34.createNamedQuery(Unknown Source)
at
ca.BidSpec.emall.stores.StoreFactoryImpl.getStoreValueObjectByName 
(StoreFactoryI

mpl.java:88)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:39)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.jav

a:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflectio 
n(AopUtils

.java:280)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoi 
npoint(Ref

lectiveMethodInvocation.java:187)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed 
(ReflectiveM

JPA Bug:Nesting of Emebedded in Embeddable element

2007-04-04 Thread Sharath_H


Hi,
 
In orm_1_0.xsd or orm-xsd.rsrc files under the xsd:complexType 
name=embeddable-attributes the xsd:element name=embedded 
type=orm:embeddedminOccurs=0 maxOccurs=unbounded/ is not present.
 
Please let me know if there is any valid reason behind it.Was the embedded 
element in embeddable-attributes was accidently missed out?
 
I faced the issue when i tried the example something like as shown below:
 
class A
{
  int id;
  B objB;
  
}
 
class B
{
  String str1;
  Date d;
  C objC;
}
 
class C
{
   String str2;
}
 
I wanted to persist object A into a single table by having object B as embedded 
and object B inturn having object C as embedded.
My corresponding orm mapping file is as shown below:
 
?xml version=1.0 encoding=UTF-8?
entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm; 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation=http://java.sun.com/xml/ns/persistence/orm orm_1_0.xsd 
version=1.0
 
entity class=A
table name=TableA/
attributes 
id name=id
 column name=ID/   
/id  
embedded name=objB/
/attributes
/entity
 
embeddable class=B  
attributes  
basic name=str1
   column name=COL2/
/basic 
basic name=d
   column name=DateCol/
/basic
embedded name=objC/
/embeddable

embeddable class=C  
attributes 
basic name=str2
   column name=COL3/
/basic 
/embeddable

/entity-mappings
 
This was not possible due to orm schema restriction.
 
 
 
Thanks,
Regards,
Sharath.H

 CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are 
not to copy, disclose, or distribute this e-mail or its contents to any other 
person and any such actions are unlawful. This e-mail may contain viruses. 
Infosys has taken every reasonable precaution to minimize this risk, but is not 
liable for any damage you may sustain as a result of any virus in this e-mail. 
You should carry out your own virus checks before opening the e-mail or 
attachment. Infosys reserves the right to monitor and review the content of all 
messages sent to or from this e-mail address. Messages sent to or from this 
e-mail address may be stored on the Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***

RE: JPA Bug:Nesting of Emebedded in Embeddable element

2007-04-04 Thread Patrick Linskey

That's just a limitation of the JPA spec. See section 9.1.34.

OpenJPA supports embedded fields in embeddable instances, as well as
various other usages of embedded things, but those are extensions to the
spec. Due to OPENJPA-125, you can only configure nested embeddeds via
annotations currently.

-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: Sharath_H [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, April 04, 2007 2:16 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: JPA Bug:Nesting of Emebedded in Embeddable element
 
 
 Hi,
  
 In orm_1_0.xsd or orm-xsd.rsrc files under the 
 xsd:complexType name=embeddable-attributes the 
 xsd:element name=embedded type=orm:embedded
 minOccurs=0 maxOccurs=unbounded/ is not present.
  
 Please let me know if there is any valid reason behind it.Was 
 the embedded element in embeddable-attributes was accidently 
 missed out?
  
 I faced the issue when i tried the example something like as 
 shown below:
  
 class A
 {
   int id;
   B objB;
   
 }
  
 class B
 {
   String str1;
   Date d;
   C objC;
 }
  
 class C
 {
String str2;
 }
  
 I wanted to persist object A into a single table by having 
 object B as embedded and object B inturn having object C as embedded.
 My corresponding orm mapping file is as shown below:
  
 ?xml version=1.0 encoding=UTF-8?
 entity-mappings 
 xmlns=http://java.sun.com/xml/ns/persistence/orm; 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; 
 xsi:schemaLocation=http://java.sun.com/xml/ns/persistence/orm
  orm_1_0.xsd version=1.0
  
 entity class=A
 table name=TableA/
 attributes 
 id name=id
  column name=ID/   
 /id  
 embedded name=objB/
 /attributes
 /entity
  
 embeddable class=B  
 attributes  
 basic name=str1
column name=COL2/
 /basic 
 basic name=d
column name=DateCol/
 /basic
 embedded name=objC/
 /embeddable
 
 embeddable class=C  
 attributes 
 basic name=str2
column name=COL3/
 /basic 
 /embeddable
 
 /entity-mappings
  
 This was not possible due to orm schema restriction.
  
  
  
 Thanks,
 Regards,
 Sharath.H
 
  CAUTION - Disclaimer *
 This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION 
 intended solely for the use of the addressee(s). If you are 
 not the intended recipient, please notify the sender by 
 e-mail and delete the original message. Further, you are not 
 to copy, disclose, or distribute this e-mail or its contents 
 to any other person and any such actions are unlawful. This 
 e-mail may contain viruses. Infosys has taken every 
 reasonable precaution to minimize this risk, but is not 
 liable for any damage you may sustain as a result of any 
 virus in this e-mail. You should carry out your own virus 
 checks before opening the e-mail or attachment. Infosys 
 reserves the right to monitor and review the content of all 
 messages sent to or from this e-mail address. Messages sent 
 to or from this e-mail address may be stored on the Infosys 
 e-mail system.
 ***INFOSYS End of Disclaimer INFOSYS***
 

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.

API or Query hints

2007-04-04 Thread Craig L Russell

I think any time we make a change to the external view of the project  
we need to have a discussion first.


IMHO The JIRA process is pretty good for this kind of stuff. Someone  
proposes a feature with non-standardized external behavior and writes  
up what it should look like. Then we agree on the details and go for it.


On this particular issue, I can see valid reasons for having an API  
that modifies the behavior of the query, but also understand why it  
might be good to mirror that behavior using query hints. But  
whichever way we go, we need to agree on the name and semantics of  
the API/property and how to pass it to the internal structures for  
execution.


There is a danger in thinking of these as hints. As I would like to  
see it, the only down side to not recognizing a query hint is lower  
performance. But if your application doesn't behave correctly if the  
implementation can't do anything useful with the hint, then it's not  
a hint but an application requirement. And if the hint can only be  
executed in some specific databases, then we need to decide if we  
throw an exception if the database isn't capable.


Craig

On Apr 4, 2007, at 2:17 PM, Abe White wrote:


... for certain values of our. I think that it's important that we
discuss API decisions as a group, as they have significant impacts on
the OpenJPA product moving forward. This is especially important when
there are dissenting views on a particular API decision, as is the
case
here.


I agree with Patrick.  API decisions need to be better thought out.
For example, even if we decide as a group to use hints in this case,
the names of the hints are important.  The current hint names you
chose are inconsistent with other OpenJPA hints in naming style and
capitalization.


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.


Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!



smime.p7s
Description: S/MIME cryptographic signature

[jira] Created: (OPENJPA-199) bulk update gets parsing exception trying to update an attribute of an embedded class

2007-04-04 Thread George Hongell (JIRA)

bulk update gets parsing exception trying to update an attribute of an embedded 
class
-

 Key: OPENJPA-199
 URL: https://issues.apache.org/jira/browse/OPENJPA-199
 Project: OpenJPA
  Issue Type: Bug
  Components: query
Affects Versions: 0.9.7
 Environment: 0.9.7-incubating-SNAPSHOT
Reporter: George Hongell
 Attachments: embeddedBugWineryTest.zip

4|false|0.9.7-incubating-SNAPSHOT 
org.apache.openjpa.persistence.ArgumentException: An error occurred while 
parsing the query filter 'update Wine w set w.label.wineName = ?1'. Error 
message: 4|false|0.9.7-incubating-SNAPSHOT 
org.apache.openjpa.kernel.jpql.ParseException: Encountered . at character 26, 
but expected: [=].
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.parse(JPQLExpressionBuilder.java:1661)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.init(JPQLExpressionBuilder.java:1641)
at org.apache.openjpa.kernel.jpql.JPQLParser.parse(JPQLParser.java:44)
at 
org.apache.openjpa.kernel.ExpressionStoreQuery.newCompilation(ExpressionStoreQuery.java:141)
at 
org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:643)
at 
org.apache.openjpa.kernel.QueryImpl.compilationFromCache(QueryImpl.java:625)
at 
org.apache.openjpa.kernel.QueryImpl.compileForCompilation(QueryImpl.java:591)
at 
org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:653)
at org.apache.openjpa.kernel.QueryImpl.getOperation(QueryImpl.java:1475)
at 
org.apache.openjpa.kernel.DelegatingQuery.getOperation(DelegatingQuery.java:120)
at 
org.apache.openjpa.persistence.QueryImpl.executeUpdate(QueryImpl.java:305)
at 
com.ibm.websphere.ejb3sample.winetour.bug.BugWineryTest.testBulkUpdate(BugWineryTest.java:551)
at 
com.ibm.websphere.ejb3sample.winetour.bug.BugWineryTest.main(BugWineryTest.java:141)
Caused by: 4|false|0.9.7-incubating-SNAPSHOT 
org.apache.openjpa.persistence.ArgumentException: Encountered . at character 
26, but expected: [=].
at 
org.apache.openjpa.kernel.jpql.JPQL.generateParseException(JPQL.java:9322)
at org.apache.openjpa.kernel.jpql.JPQL.jj_consume_token(JPQL.java:9199)
at org.apache.openjpa.kernel.jpql.JPQL.EQ(JPQL.java:5718)
at org.apache.openjpa.kernel.jpql.JPQL.update_item(JPQL.java:729)
at org.apache.openjpa.kernel.jpql.JPQL.set_clause(JPQL.java:706)
at org.apache.openjpa.kernel.jpql.JPQL.update_clause(JPQL.java:701)
at org.apache.openjpa.kernel.jpql.JPQL.update_statement(JPQL.java:147)
at org.apache.openjpa.kernel.jpql.JPQL.parseQuery(JPQL.java:65)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.parse(JPQLExpressionBuilder.java:1654)
... 12 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-199) bulk update gets parsing exception trying to update an attribute of an embedded class

2007-04-04 Thread George Hongell (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Hongell updated OPENJPA-199:
---

Attachment: embeddedBugWineryTest.zip

 bulk update gets parsing exception trying to update an attribute of an 
 embedded class
 -

 Key: OPENJPA-199
 URL: https://issues.apache.org/jira/browse/OPENJPA-199
 Project: OpenJPA
  Issue Type: Bug
  Components: query
Affects Versions: 0.9.7
 Environment: 0.9.7-incubating-SNAPSHOT
Reporter: George Hongell
 Attachments: embeddedBugWineryTest.zip


 4|false|0.9.7-incubating-SNAPSHOT 
 org.apache.openjpa.persistence.ArgumentException: An error occurred while 
 parsing the query filter 'update Wine w set w.label.wineName = ?1'. Error 
 message: 4|false|0.9.7-incubating-SNAPSHOT 
 org.apache.openjpa.kernel.jpql.ParseException: Encountered . at character 
 26, but expected: [=].
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.parse(JPQLExpressionBuilder.java:1661)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.init(JPQLExpressionBuilder.java:1641)
   at org.apache.openjpa.kernel.jpql.JPQLParser.parse(JPQLParser.java:44)
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery.newCompilation(ExpressionStoreQuery.java:141)
   at 
 org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:643)
   at 
 org.apache.openjpa.kernel.QueryImpl.compilationFromCache(QueryImpl.java:625)
   at 
 org.apache.openjpa.kernel.QueryImpl.compileForCompilation(QueryImpl.java:591)
   at 
 org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:653)
   at org.apache.openjpa.kernel.QueryImpl.getOperation(QueryImpl.java:1475)
   at 
 org.apache.openjpa.kernel.DelegatingQuery.getOperation(DelegatingQuery.java:120)
   at 
 org.apache.openjpa.persistence.QueryImpl.executeUpdate(QueryImpl.java:305)
   at 
 com.ibm.websphere.ejb3sample.winetour.bug.BugWineryTest.testBulkUpdate(BugWineryTest.java:551)
   at 
 com.ibm.websphere.ejb3sample.winetour.bug.BugWineryTest.main(BugWineryTest.java:141)
 Caused by: 4|false|0.9.7-incubating-SNAPSHOT 
 org.apache.openjpa.persistence.ArgumentException: Encountered . at 
 character 26, but expected: [=].
   at 
 org.apache.openjpa.kernel.jpql.JPQL.generateParseException(JPQL.java:9322)
   at org.apache.openjpa.kernel.jpql.JPQL.jj_consume_token(JPQL.java:9199)
   at org.apache.openjpa.kernel.jpql.JPQL.EQ(JPQL.java:5718)
   at org.apache.openjpa.kernel.jpql.JPQL.update_item(JPQL.java:729)
   at org.apache.openjpa.kernel.jpql.JPQL.set_clause(JPQL.java:706)
   at org.apache.openjpa.kernel.jpql.JPQL.update_clause(JPQL.java:701)
   at org.apache.openjpa.kernel.jpql.JPQL.update_statement(JPQL.java:147)
   at org.apache.openjpa.kernel.jpql.JPQL.parseQuery(JPQL.java:65)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.parse(JPQLExpressionBuilder.java:1654)
   ... 12 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS

2007-04-04 Thread Patrick Linskey (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Patrick Linskey updated OPENJPA-182:

Attachment: OPENJPA-182.patch

For the sake of discussion, I've attached an alternate patch that uses a new
JDBCFetchPlan.setIsolationLevel() instead of a hint for isolation level, and
uses JDBCFetchConfiguration.getReadLockLevel() to determine whether or not to
do a SELECT ... FOR UPDATE.

If the read lock level is set to LockLevels.LEVEL_WRITE, then the FOR UPDATE is
included; if the read lock level is set to LockLevels.LEVEL_READ, then no FOR
UPDATE is used. If the read lock level is LockLevels.LEVEL_NONE, then the
default behavior is used. (This is possibly not the best use of LEVEL_NONE --
I'm not sure if LEVEL_NONE means 'default' or something else. But for the
purposes of demonstration, it seemed expedient to use it. Adding a new
LEVEL_DEFAULT constant might make more sense.)

Also, I directly reused the java.sql.Connection constants, which is possibly
non-ideal; we might want to discuss making our own constants. Or not.

So, in this model, if there were a test case for this stuff, I would have
changed the test case to do:

Query q = em.createQuery(...);
JDBCFetchPlan plan = (JDBCFetchPlan) ((OpenJPAQuery) query).getFetchPlan();
plan.setIsolationLevel(Connection.TRANSACTION_SERIALIZABLE);
plan.setReadLockMode(LockModeType.WRITE); // force a FOR UPDATE
List l = q.getResultList();

Note also that this model allows the isolation level and read lock mode to be
configured on the EM itself, for use in find() calls and relationship lookups,
and as the default settings for the fetch plans of queries created from the EM.

Finally, I replicated the logic in DB2Dictionary, but I noticed that sometimes
the logic checked for serializable and sometimes it checked for
read-uncommitted. I preserved these checks, but was this intentional? I'm not
all that clear about what the optimizations are, so just wanted to ensure that
that wasn't a typo.

db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
--

Key: OPENJPA-182
URL: https://issues.apache.org/jira/browse/OPENJPA-182
Project: OpenJPA
Issue Type: New Feature
Components: jdbc
Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux
Reporter: David Wisneski
Assigned To: David Wisneski
Attachments: OPENJPA-182.patch, openJPA182.patch

A while back we changed the syntax of update locking from FOR UPDATE OF to
WITH RS USE AND KEEP UPDATE LOCKS. Additional changes are required because
1. if isolation=serializable is configured, then the syntax should be WITH
RR USE AND KEEP UDPATE LOCKS
2. when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND
KEEP EXCLUSIVE LOCKS or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400
only supports read or exclusive locks.
3. DB2 supports both a FETCH FIRST ROWS and update LOCKS clauses.
So we change supportsLockingWithSelectRange = true in the
AbstractDB2Dictionary class and change the DB2Dictionary to append the
correct LOCKS syntax depending on vendor, release and isolation level.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

RE: API or Query hints

2007-04-04 Thread Patrick Linskey

Hi,

In the interests of putting my money where my mouth is, I attached a
patch to the JIRA issue, and included a description of the patch in the
JIRA issue. Hopefully, this will help a) make the problem and different
solutions more concrete, and b) quell any concerns about
implementability of the approach that I outlined.

-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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, April 04, 2007 3:22 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: API or Query hints
 
 I think any time we make a change to the external view of the 
 project  
 we need to have a discussion first.
 
 IMHO The JIRA process is pretty good for this kind of stuff. Someone  
 proposes a feature with non-standardized external behavior 
 and writes  
 up what it should look like. Then we agree on the details and 
 go for it.
 
 On this particular issue, I can see valid reasons for having an API  
 that modifies the behavior of the query, but also understand why it  
 might be good to mirror that behavior using query hints. But  
 whichever way we go, we need to agree on the name and semantics of  
 the API/property and how to pass it to the internal structures for  
 execution.
 
 There is a danger in thinking of these as hints. As I would 
 like to  
 see it, the only down side to not recognizing a query hint is lower  
 performance. But if your application doesn't behave correctly if the  
 implementation can't do anything useful with the hint, then it's not  
 a hint but an application requirement. And if the hint can only be  
 executed in some specific databases, then we need to decide if we  
 throw an exception if the database isn't capable.
 
 Craig
 
 On Apr 4, 2007, at 2:17 PM, Abe White wrote:
 
  ... for certain values of our. I think that it's 
 important that we
  discuss API decisions as a group, as they have significant 
 impacts on
  the OpenJPA product moving forward. This is especially 
 important when
  there are dissenting views on a particular API decision, as is the
  case
  here.
 
  I agree with Patrick.  API decisions need to be better thought out.
  For example, even if we decide as a group to use hints in this case,
  the names of the hints are important.  The current hint names you
  chose are inconsistent with other OpenJPA hints in naming style and
  capitalization.
 
 
  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.
 
 Craig Russell
 Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
 408 276-5638 mailto:[EMAIL PROTECTED]
 P.S. A good JDO? O, Gasp!
 
 

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.

[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS

2007-04-04 Thread Craig Russell (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486812
]

Craig Russell commented on OPENJPA-182:
---

A use-case for the isolation level is to support different locking semantics
for different classes and possibly for different queries. To use Patrick's
patch would I need to use a different fetch plan before issuing a find or a
query and then set it back after that method call? Or can I specify an
isolation level in the FetchConfiguration per class?

db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
--

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-200) cannot use enum type as input parameter for a query, and you cannot specify an Enum type as a literal, this also means that there is no way to update an enum type using j

2007-04-04 Thread George Hongell (JIRA)

cannot use enum type as input parameter for a query, and you cannot specify an 
Enum type as a literal, this also means that there is no way to update an enum 
type using jpaql bulk update
--

 Key: OPENJPA-200
 URL: https://issues.apache.org/jira/browse/OPENJPA-200
 Project: OpenJPA
  Issue Type: Bug
  Components: query
Affects Versions: 0.9.7
 Environment: 0.9.7-incubating-SNAPSHOT
Reporter: George Hongell
 Attachments: enumBugWineryTest.zip

cannot use enum as input parameter for a query, Enum cannot be used as argument 
in setParm, since you also cannot specify an Enum type as a literal, this means 
that there is no way to update an enum type using jpaql bulk  update 

update Wine w set w.type = ?1 where w.type = ?2

4|false|0.9.7-incubating-SNAPSHOT 
org.apache.openjpa.persistence.ArgumentException: The specified parameter of 
type class com.ibm.websphere.ejb3sample.winetour.bug.Wine$WineType is not a 
valid query parameter.
at 
org.apache.openjpa.jdbc.sql.DBDictionary.setUnknown(DBDictionary.java:1273)
at 
org.apache.openjpa.jdbc.sql.SQLBuffer.setParameters(SQLBuffer.java:564)
at 
org.apache.openjpa.jdbc.sql.SQLBuffer.prepareStatement(SQLBuffer.java:475)
at 
org.apache.openjpa.jdbc.sql.SQLBuffer.prepareStatement(SQLBuffer.java:451)
at 
org.apache.openjpa.jdbc.sql.SQLBuffer.prepareStatement(SQLBuffer.java:440)
at 
org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeBulkOperation(JDBCStoreQuery.java:490)
at 
org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeUpdate(JDBCStoreQuery.java:420)
at 
org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeUpdate(ExpressionStoreQuery.java:687)
at org.apache.openjpa.kernel.QueryImpl.update(QueryImpl.java:1030)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:795)
at org.apache.openjpa.kernel.QueryImpl.updateAll(QueryImpl.java:870)
at 
org.apache.openjpa.kernel.DelegatingQuery.updateAll(DelegatingQuery.java:568)
at 
org.apache.openjpa.persistence.QueryImpl.executeUpdate(QueryImpl.java:316)
at 
com.ibm.websphere.ejb3sample.winetour.bug.BugWineryTest.testBulkUpdate(BugWineryTest.java:553)

=
update Wine w set w.type = +Wine.WineType.Propriatory+ where w.type = 
+Wine.WineType.Varietal 

4|false|0.9.7-incubating-SNAPSHOT 
org.apache.openjpa.persistence.ArgumentException: null
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:800)
at org.apache.openjpa.kernel.QueryImpl.updateAll(QueryImpl.java:870)
at org.apache.openjpa.kernel.QueryImpl.updateAll(QueryImpl.java:866)
at 
org.apache.openjpa.kernel.DelegatingQuery.updateAll(DelegatingQuery.java:560)
at 
org.apache.openjpa.persistence.QueryImpl.executeUpdate(QueryImpl.java:319)
at 
com.ibm.websphere.ejb3sample.winetour.bug.BugWineryTest.testBulkUpdate(BugWineryTest.java:557)
at 
com.ibm.websphere.ejb3sample.winetour.bug.BugWineryTest.main(BugWineryTest.java:141)
Caused by: java.lang.NullPointerException
at 
org.apache.openjpa.jdbc.kernel.exps.PCPath.initialize(PCPath.java:442)
at 
org.apache.openjpa.jdbc.kernel.exps.CompareEqualExpression.initialize(CompareEqualExpression.java:77)
at 
org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.initialize(SelectConstructor.java:175)
at 
org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.newSelect(SelectConstructor.java:116)
at 
org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.evaluate(SelectConstructor.java:70)
at 
org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeBulkOperation(JDBCStoreQuery.java:458)
at 
org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeUpdate(JDBCStoreQuery.java:420)
at 
org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeUpdate(ExpressionStoreQuery.java:687)
at org.apache.openjpa.kernel.QueryImpl.update(QueryImpl.java:1030)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:795)
... 6 more
at 
com.ibm.websphere.ejb3sample.winetour.bug.BugWineryTest.main(BugWineryTest.java:141)

=
update Wine w set w.type = 'Propriatory' where w.type = 'Varietal'

4|false|0.9.7-incubating-SNAPSHOT 
org.apache.openjpa.persistence.ArgumentException: java.lang.String incompatible 
with java.lang.Enum
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:800)
at org.apache.openjpa.kernel.QueryImpl.updateAll(QueryImpl.java:870)
at

[jira] Updated: (OPENJPA-200) cannot use enum type as input parameter for a query, and you cannot specify an Enum type as a literal, this also means that there is no way to update an enum type using j

2007-04-04 Thread George Hongell (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Hongell updated OPENJPA-200:
---

Attachment: enumBugWineryTest.zip

run main to get error

 cannot use enum type as input parameter for a query, and you cannot specify 
 an Enum type as a literal, this also means that there is no way to update an 
 enum type using jpaql bulk update
 --

 Key: OPENJPA-200
 URL: https://issues.apache.org/jira/browse/OPENJPA-200
 Project: OpenJPA
  Issue Type: Bug
  Components: query
Affects Versions: 0.9.7
 Environment: 0.9.7-incubating-SNAPSHOT
Reporter: George Hongell
 Attachments: enumBugWineryTest.zip


 cannot use enum as input parameter for a query, Enum cannot be used as 
 argument in setParm, since you also cannot specify an Enum type as a literal, 
 this means that there is no way to update an enum type using jpaql bulk  
 update 
 update Wine w set w.type = ?1 where w.type = ?2
 4|false|0.9.7-incubating-SNAPSHOT 
 org.apache.openjpa.persistence.ArgumentException: The specified parameter of 
 type class com.ibm.websphere.ejb3sample.winetour.bug.Wine$WineType is not a 
 valid query parameter.
   at 
 org.apache.openjpa.jdbc.sql.DBDictionary.setUnknown(DBDictionary.java:1273)
   at 
 org.apache.openjpa.jdbc.sql.SQLBuffer.setParameters(SQLBuffer.java:564)
   at 
 org.apache.openjpa.jdbc.sql.SQLBuffer.prepareStatement(SQLBuffer.java:475)
   at 
 org.apache.openjpa.jdbc.sql.SQLBuffer.prepareStatement(SQLBuffer.java:451)
   at 
 org.apache.openjpa.jdbc.sql.SQLBuffer.prepareStatement(SQLBuffer.java:440)
   at 
 org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeBulkOperation(JDBCStoreQuery.java:490)
   at 
 org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeUpdate(JDBCStoreQuery.java:420)
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeUpdate(ExpressionStoreQuery.java:687)
   at org.apache.openjpa.kernel.QueryImpl.update(QueryImpl.java:1030)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:795)
   at org.apache.openjpa.kernel.QueryImpl.updateAll(QueryImpl.java:870)
   at 
 org.apache.openjpa.kernel.DelegatingQuery.updateAll(DelegatingQuery.java:568)
   at 
 org.apache.openjpa.persistence.QueryImpl.executeUpdate(QueryImpl.java:316)
   at 
 com.ibm.websphere.ejb3sample.winetour.bug.BugWineryTest.testBulkUpdate(BugWineryTest.java:553)
 =
 update Wine w set w.type = +Wine.WineType.Propriatory+ where w.type = 
 +Wine.WineType.Varietal 
 4|false|0.9.7-incubating-SNAPSHOT 
 org.apache.openjpa.persistence.ArgumentException: null
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:800)
   at org.apache.openjpa.kernel.QueryImpl.updateAll(QueryImpl.java:870)
   at org.apache.openjpa.kernel.QueryImpl.updateAll(QueryImpl.java:866)
   at 
 org.apache.openjpa.kernel.DelegatingQuery.updateAll(DelegatingQuery.java:560)
   at 
 org.apache.openjpa.persistence.QueryImpl.executeUpdate(QueryImpl.java:319)
   at 
 com.ibm.websphere.ejb3sample.winetour.bug.BugWineryTest.testBulkUpdate(BugWineryTest.java:557)
   at 
 com.ibm.websphere.ejb3sample.winetour.bug.BugWineryTest.main(BugWineryTest.java:141)
 Caused by: java.lang.NullPointerException
   at 
 org.apache.openjpa.jdbc.kernel.exps.PCPath.initialize(PCPath.java:442)
   at 
 org.apache.openjpa.jdbc.kernel.exps.CompareEqualExpression.initialize(CompareEqualExpression.java:77)
   at 
 org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.initialize(SelectConstructor.java:175)
   at 
 org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.newSelect(SelectConstructor.java:116)
   at 
 org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.evaluate(SelectConstructor.java:70)
   at 
 org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeBulkOperation(JDBCStoreQuery.java:458)
   at 
 org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeUpdate(JDBCStoreQuery.java:420)
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeUpdate(ExpressionStoreQuery.java:687)
   at org.apache.openjpa.kernel.QueryImpl.update(QueryImpl.java:1030)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:795)
   ... 6 more
   at 
 com.ibm.websphere.ejb3sample.winetour.bug.BugWineryTest.main(BugWineryTest.java:141)
 =
 update Wine w set w.type = 'Propriatory' where w.type = 'Varietal'
 4|false|0.9.7-incubating-SNAPSHOT

[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS

2007-04-04 Thread Patrick Linskey (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486819
]

Patrick Linskey commented on OPENJPA-182:
-

In the hint-based approach, you could set the hints on a particular query.

In my approach, you could configure the FetchPlan for a particular query (get
the Query's fetch plan), or for a particular entity manager (get the EM's fetch
plan). To do different fetch plans for different queries, you'd just set the
different query fetch plans differently.

Query fetch plans are a copy-on-write semantic -- they start off just
delegating through to the EM's fetch plan, and if you make changes, then they
immediately make a copy of the EM's fetch plan, and remain isolated from the
EM's fetch plan from then on out.

If you wanted to do different isolation levels for different find() calls or
different relationship traversals, in my impl, you'd need to set the EM's fetch
plan, do the work, then set it back. In the hint-based impl, you would not be
able to do any configuration for find() or relationship traversals.

db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
--

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-201) Mapping Tool ignores the @JoinColumn annotation in a @ManyToOne mapping if the table argument is used

2007-04-04 Thread George Hongell (JIRA)

Mapping Tool ignores the @JoinColumn annotation in a @ManyToOne mapping if the 
table argument is used
-

 Key: OPENJPA-201
 URL: https://issues.apache.org/jira/browse/OPENJPA-201
 Project: OpenJPA
  Issue Type: Bug
 Environment: 0.9.7-incubating-SNAPSHOT
Reporter: George Hongell


@Entity  
@Table(name=CxWine)
public class Wine {
@Id
private Integer wineid;
...
@ManyToOne()
@JoinColumn(name=NEW_WINERY_WINERYID, referencedColumnName=WINERYID,  
table=cxWinery)

//ignored @JoinColumn(name=NEW_WINERY_WINERYID, 
referencedColumnName=WINERYID,  table=cxWinery)
//ignored @JoinColumn(name=NEW_WINERY_WINERYID, 
referencedColumnName=WINERYID,  table=cxWinery)
//ignored  @JoinColumn(name=NEW_WINERY_WINERYID,  table=cxWINERY)
//ok@JoinColumn(name=NEW_WINERY_WINERYID, referencedColumnName=wineryid)
//ok@JoinColumn(name=NEW_WINERY_WINERYID)
private Winery winery;
...
}


generates
2744  cxwineTour  TRACE  [main] openjpa.jdbc.SQL - t 1094861122, conn 
98698722 executing stmnt 1325027066 CREATE TABLE CxWine (wineid INTEGER NOT 
NULL, cost SMALLINT, description VARCHAR(254), minimumHoldYears INTEGER, rating 
SMALLINT, stockCount INTEGER, type VARCHAR(20), version INTEGER, alcoholPercent 
DOUBLE, ava VARCHAR(40), bottler VARCHAR(40), brandName VARCHAR(40), 
labelWineClass VARCHAR(20), labelWineColor VARCHAR(20), estateBottled SMALLINT, 
hasSulfites SMALLINT, labelid INTEGER, mlContents INTEGER, qualityDesignation 
VARCHAR(40), vineyardName VARCHAR(40), vintage TIMESTAMP, wineName VARCHAR(40), 
winery_wineryid INTEGER, PRIMARY KEY (wineid))


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-201) Mapping Tool ignores the @JoinColumn annotation in a @ManyToOne mapping if the table argument is used

2007-04-04 Thread George Hongell (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Hongell updated OPENJPA-201:
---

Priority: Minor  (was: Major)

 Mapping Tool ignores the @JoinColumn annotation in a @ManyToOne mapping if 
 the table argument is used
 -

 Key: OPENJPA-201
 URL: https://issues.apache.org/jira/browse/OPENJPA-201
 Project: OpenJPA
  Issue Type: Bug
 Environment: 0.9.7-incubating-SNAPSHOT
Reporter: George Hongell
Priority: Minor

 @Entity
 @Table(name=CxWine)
 public class Wine {
   @Id
   private Integer wineid;
 ...
   @ManyToOne()
 @JoinColumn(name=NEW_WINERY_WINERYID, referencedColumnName=WINERYID,  
 table=cxWinery)
 //ignored @JoinColumn(name=NEW_WINERY_WINERYID, 
 referencedColumnName=WINERYID,  table=cxWinery)
 //ignored @JoinColumn(name=NEW_WINERY_WINERYID, 
 referencedColumnName=WINERYID,  table=cxWinery)
 //ignored  @JoinColumn(name=NEW_WINERY_WINERYID,  table=cxWINERY)
 //ok  @JoinColumn(name=NEW_WINERY_WINERYID, referencedColumnName=wineryid)
 //ok  @JoinColumn(name=NEW_WINERY_WINERYID)
   private Winery winery;
 ...
 }
 generates
 2744  cxwineTour  TRACE  [main] openjpa.jdbc.SQL - t 1094861122, conn 
 98698722 executing stmnt 1325027066 CREATE TABLE CxWine (wineid INTEGER NOT 
 NULL, cost SMALLINT, description VARCHAR(254), minimumHoldYears INTEGER, 
 rating SMALLINT, stockCount INTEGER, type VARCHAR(20), version INTEGER, 
 alcoholPercent DOUBLE, ava VARCHAR(40), bottler VARCHAR(40), brandName 
 VARCHAR(40), labelWineClass VARCHAR(20), labelWineColor VARCHAR(20), 
 estateBottled SMALLINT, hasSulfites SMALLINT, labelid INTEGER, mlContents 
 INTEGER, qualityDesignation VARCHAR(40), vineyardName VARCHAR(40), vintage 
 TIMESTAMP, wineName VARCHAR(40), winery_wineryid INTEGER, PRIMARY KEY 
 (wineid))

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS

2007-04-04 Thread Patrick Linskey (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486821
]

Patrick Linskey commented on OPENJPA-182:
-

It's probably worth noting that everything in the FetchPlan is configurable via
the Query.setHint() APIs. My earlier theoretical test case would become:

Query q = em.createQuery(...);
q.setHint(openjpa.FetchPlan.IsolationLevel,
Connection.TRANSACTION_SERIALIZABLE);
q.setHint(openjpa.FetchPlan.ReadLockMode, LockModeType.WRITE);
List l = q.getResultList();

In other words, if we use the patch that I attached (or something like it), we
will end up with strong typing, API alignment with similar concepts, and
dynamic accessibility both in terms of Query.setHint() and @QueryHints
annotations / query-hint XML.

db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
--

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-202) after invoking LRS processing in a client by calling an @LRS annotated relationship, the next em.clear()/em.close() gets org.apache.openjpa.persistence.InvalidStateExcept

2007-04-04 Thread George Hongell (JIRA)

after invoking LRS processing in a client by calling an @LRS annotated 
relationship, the next em.clear()/em.close() gets 
org.apache.openjpa.persistence.InvalidStateException: You cannot transfer large 
result set fields from one object or field to another
--

 Key: OPENJPA-202
 URL: https://issues.apache.org/jira/browse/OPENJPA-202
 Project: OpenJPA
  Issue Type: Bug
  Components: kernel
Affects Versions: 0.9.7
 Environment: 0.9.7-incubating-SNAPSHOT
Reporter: George Hongell


after invoking LRS processing in a client by calling an @LRS annotated 
relationship, the next em.clear()/em.close() gets 
org.apache.openjpa.persistence.InvalidStateException: You cannot transfer large 
result set fields from one object or field to another

4|false|0.9.7-incubating-SNAPSHOT 
org.apache.openjpa.persistence.InvalidStateException: You cannot transfer large 
result set fields from one object or field to another.
at 
org.apache.openjpa.util.AbstractLRSProxyCollection.setOwner(AbstractLRSProxyCollection.java:77)
at 
org.apache.openjpa.kernel.DetachManager$DetachFieldManager.reproxy(DetachManager.java:523)
at 
org.apache.openjpa.kernel.DetachManager.detachInternal(DetachManager.java:431)
at 
org.apache.openjpa.kernel.DetachManager.detachAll(DetachManager.java:299)
at 
org.apache.openjpa.kernel.BrokerImpl.detachAllInternal(BrokerImpl.java:3150)
at org.apache.openjpa.kernel.BrokerImpl.detachAll(BrokerImpl.java:3123)
at 
org.apache.openjpa.kernel.DelegatingBroker.detachAll(DelegatingBroker.java:1136)
at 
org.apache.openjpa.persistence.EntityManagerImpl.clear(EntityManagerImpl.java:868)
at 
com.ibm.websphere.ejb3sample.winetour.bug.BugWineryTest.testLargeResultSetAnnotation(BugWineryTest.java:902)
at 
com.ibm.websphere.ejb3sample.winetour.bug.BugWineryTest.main(BugWineryTest.java:146)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-202) after invoking LRS processing in a client by calling an @LRS annotated relationship, the next em.clear()/em.close() gets org.apache.openjpa.persistence.InvalidStateExcept

2007-04-04 Thread George Hongell (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Hongell updated OPENJPA-202:
---

Attachment: lrsBugWineryTest.zip

run main method to get error

 after invoking LRS processing in a client by calling an @LRS annotated 
 relationship, the next em.clear()/em.close() gets 
 org.apache.openjpa.persistence.InvalidStateException: You cannot transfer 
 large result set fields from one object or field to another
 --

 Key: OPENJPA-202
 URL: https://issues.apache.org/jira/browse/OPENJPA-202
 Project: OpenJPA
  Issue Type: Bug
  Components: kernel
Affects Versions: 0.9.7
 Environment: 0.9.7-incubating-SNAPSHOT
Reporter: George Hongell
 Attachments: lrsBugWineryTest.zip


 after invoking LRS processing in a client by calling an @LRS annotated 
 relationship, the next em.clear()/em.close() gets 
 org.apache.openjpa.persistence.InvalidStateException: You cannot transfer 
 large result set fields from one object or field to another
 4|false|0.9.7-incubating-SNAPSHOT 
 org.apache.openjpa.persistence.InvalidStateException: You cannot transfer 
 large result set fields from one object or field to another.
   at 
 org.apache.openjpa.util.AbstractLRSProxyCollection.setOwner(AbstractLRSProxyCollection.java:77)
   at 
 org.apache.openjpa.kernel.DetachManager$DetachFieldManager.reproxy(DetachManager.java:523)
   at 
 org.apache.openjpa.kernel.DetachManager.detachInternal(DetachManager.java:431)
   at 
 org.apache.openjpa.kernel.DetachManager.detachAll(DetachManager.java:299)
   at 
 org.apache.openjpa.kernel.BrokerImpl.detachAllInternal(BrokerImpl.java:3150)
   at org.apache.openjpa.kernel.BrokerImpl.detachAll(BrokerImpl.java:3123)
   at 
 org.apache.openjpa.kernel.DelegatingBroker.detachAll(DelegatingBroker.java:1136)
   at 
 org.apache.openjpa.persistence.EntityManagerImpl.clear(EntityManagerImpl.java:868)
   at 
 com.ibm.websphere.ejb3sample.winetour.bug.BugWineryTest.testLargeResultSetAnnotation(BugWineryTest.java:902)
   at 
 com.ibm.websphere.ejb3sample.winetour.bug.BugWineryTest.main(BugWineryTest.java:146)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

RE: Duplicate Query - where none exists

2007-04-04 Thread Phill Moran

I did a workspace search and it exists in only one place. Also if I comment out
the one it complains about it complains about the next one. But only in this
java file. I even did an clean and build to make sure there were no old class
files hanging out.

-Original Message-
From: Dain Sundstrom [mailto:[EMAIL PROTECTED] 
Sent: April 4, 2007 5:06 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Duplicate Query - where none exists

I think I saw this once.  The problem is in JPA named queries are all contained
in a single global namespace, so if you have to persistent beans that define
queries with the same name you get a warning.  It would be nice if the warning
told you where the duplicate declarations are located.

-dain

On Apr 3, 2007, at 10:07 PM, Phill Moran wrote:

 Anyone seen this before

 WARN   [main] openjpa.MetaData - Found duplicate query StoreFXPK  
 in class
 ..  Ignoring.

 This class has only three such named queries all different names and 
 different actual queries. See following @NamedQueries( {
   @NamedQuery(name = StoreFXPK, query = SELECT s FROM Store s
WHERE 
 s.id = :primaryKey),
   @NamedQuery(name = StoreFXTypeAndName, query = SELECT s FROM 
 Store s WHERE s.type = :type AND UPPER(s.name) LIKE :storeName OR
 UPPER(s.displayName) = :storeName2),
   @NamedQuery(name = StoreFXName, query = SELECT s FROM Store s

 WHERE UPPER(s.name) = :storeName OR UPPER(s.displayName) = 
 :storeName2)
   })

 I even renamed the duplicate parms to make sure it was not a trickle 
 down exception. Not only that, if I comment out the StoreFXPK query I 
 get the same error on the next named Query. I did a search on the 
 workspace an this is only used in one place (factory class) and define 
 in another (persistent class). I have no doubt this is something I 
 have done but am unsure what it is I get the follow stack trace when 
 executing the following line:

 Query q = em.createNamedQuery(StoreFXName); - not the same query 
 mentioned in the above warning...the plot thickens

 The unmapped field in the stack trace is mapped.

 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:2
 83)
   at
 org.apache.openjpa.meta.MetaDataRepository.getMetaData
 (MetaDataRepository.java:3
 38)
   at
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(
 JPQLExpres
 sionBuilder.java:151)
   at
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaD
 ata(JPQLEx
 pressionBuilder.java:131)
   at
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaD
 ata(JPQLEx
 pressionBuilder.java:211)
   at
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaD
 ata(JPQLEx
 pressionBuilder.java:181)
   at
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(
 JPQLExpres
 sionBuilder.java:174)
   at
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$500
 (JPQLExpressionBu
 ilder.java:61)
   at
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder
 $ParsedJPQL.populate(JPQLExp
 ressionBuilder.java:1657)
   at
 org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:52)
   at
 org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation
 (Expressio
 nStoreQuery.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.compile(QueryImpl.java:558)
   at
 org.apache.openjpa.persistence.EntityManagerImpl.createNamedQuery
 (EntityManagerI
 mpl.java:699)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at
 sun.reflect.NativeMethodAccessorImpl.invoke
 (NativeMethodAccessorImpl.java:39)
   at
 sun.reflect.DelegatingMethodAccessorImpl.invoke
 (DelegatingMethodAccessorImpl.jav
 a:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at
 org.springframework.orm.jpa.ExtendedEntityManagerCreator
 $ExtendedEntityManagerIn
 vocationHandler.invoke(ExtendedEntityManagerCreator.java:237)
   at $Proxy34.createNamedQuery(Unknown Source)
   at
 ca.BidSpec.emall.stores.StoreFactoryImpl.getStoreValueObjectByName
 (StoreFactoryI
 mpl.java:88)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at
 sun.reflect.NativeMethodAccessorImpl.invoke
 (NativeMethodAccessorImpl.java:39)
   at
 sun.reflect.DelegatingMethodAccessorImpl.invoke

Re: Duplicate Query - where none exists

2007-04-04 Thread Marc Prud'hommeaux


Phill-

While I'm not sure the cause of the duplicate query error, I do  
notice the original cause in the nested stack trace is:



Caused by: 4|true|0.0.0
org.apache.openjpa.persistence.ArgumentException: You cannot join on
column category.categoryTypeFK.  It is not managed by a mapping that
supports joins.


It could be that this error is indirectly causing the next one.

Have you looked into this? How is categoryTypeFK mapped?




On Apr 4, 2007, at 8:03 PM, Phill Moran wrote:

I did a workspace search and it exists in only one place. Also if I  
comment out
the one it complains about it complains about the next one. But  
only in this
java file. I even did an clean and build to make sure there were no  
old class

files hanging out.

-Original Message-
From: Dain Sundstrom [mailto:[EMAIL PROTECTED]
Sent: April 4, 2007 5:06 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Duplicate Query - where none exists

I think I saw this once.  The problem is in JPA named queries are  
all contained
in a single global namespace, so if you have to persistent beans  
that define
queries with the same name you get a warning.  It would be nice if  
the warning

told you where the duplicate declarations are located.

-dain

On Apr 3, 2007, at 10:07 PM, Phill Moran wrote:


Anyone seen this before

WARN   [main] openjpa.MetaData - Found duplicate query StoreFXPK
in class
..  Ignoring.

This class has only three such named queries all different names and
different actual queries. See following @NamedQueries( {
@NamedQuery(name = StoreFXPK, query = SELECT s FROM Store s

WHERE

s.id = :primaryKey),
@NamedQuery(name = StoreFXTypeAndName, query = SELECT s FROM
Store s WHERE s.type = :type AND UPPER(s.name) LIKE :storeName OR
UPPER(s.displayName) = :storeName2),
@NamedQuery(name = StoreFXName, query = SELECT s FROM Store s



WHERE UPPER(s.name) = :storeName OR UPPER(s.displayName) =
:storeName2)
})

I even renamed the duplicate parms to make sure it was not a trickle
down exception. Not only that, if I comment out the StoreFXPK query I
get the same error on the next named Query. I did a search on the
workspace an this is only used in one place (factory class) and  
define

in another (persistent class). I have no doubt this is something I
have done but am unsure what it is I get the follow stack trace when
executing the following line:

Query q = em.createNamedQuery(StoreFXName); - not the same query
mentioned in the above warning...the plot thickens

The unmapped field in the stack trace is mapped.

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:2
83)
at
org.apache.openjpa.meta.MetaDataRepository.getMetaData
(MetaDataRepository.java:3
38)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData 
(

JPQLExpres
sionBuilder.java:151)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMeta 
D

ata(JPQLEx
pressionBuilder.java:131)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMeta 
D

ata(JPQLEx
pressionBuilder.java:211)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMeta 
D

ata(JPQLEx
pressionBuilder.java:181)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType 
(

JPQLExpres
sionBuilder.java:174)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$500
(JPQLExpressionBu
ilder.java:61)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder
$ParsedJPQL.populate(JPQLExp
ressionBuilder.java:1657)
at
org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java: 
52)

at
org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilatio 
n

(Expressio
nStoreQuery.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.compile(QueryImpl.java:558)
at
org.apache.openjpa.persistence.EntityManagerImpl.createNamedQuery
(EntityManagerI
mpl.java:699)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.jav
a:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.springframework.orm.jpa.ExtendedEntityManagerCreator

RE: Duplicate Query - where none exists

2007-04-04 Thread Phill Moran

I think you may be on to something and have been looking into it. It is mapped
and I thought worked but I am learning that I have a pretty messed up config (I
had both Toplink and OpenJPA, I am accessing fields directly not through getters
and am not positive that the mapping is right as it is one to many). I have
other versions of the same mapping and this fairly commonly used class for my
application as it represents categories that are grouped by categoryTpye. It
does have a relation into the offended query class though

- Here is the pertinent parts of the Store class:

@ManyToOne
@JoinColumn(name = typeFK, referencedColumnName = id)
public Category getType() throws StoreTypeNotFoundException {
return type;
}

- Here is the pertinent parts of the Category class:

@Entity
@Table(name = category, schema = bidspec)
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
@NamedQueries( {
@NamedQuery(name = CategoryFXType, query = SELECT c FROM
Category c WHERE c.type = :type),
@NamedQuery(name = CategoryValueObjectFXPK, query = SELECT c
FROM Category c WHERE c.id = :primaryKey),
@NamedQuery(name = CategoryFXDescription, query = SELECT c
FROM Category c WHERE UPPER(c.description) LIKE :description ORDER BY
c.description) })
public class Category extends Persistable {

...

@ManyToOne
@JoinColumn(name = categoryTypeFK, referencedColumnName = id)
public CategoryType getType() {
return this.type;
}

Persistable is my base JPA persistable class housing the String id for all
persistable classes

-Original Message-
From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf Of Marc
Prud'hommeaux
Sent: April 4, 2007 11:13 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Duplicate Query - where none exists

Phill-

While I'm not sure the cause of the duplicate query error, I do notice the
original cause in the nested stack trace is:

 Caused by: 4|true|0.0.0
 org.apache.openjpa.persistence.ArgumentException: You cannot join on 
 column category.categoryTypeFK.  It is not managed by a mapping that 
 supports joins.

It could be that this error is indirectly causing the next one.

Have you looked into this? How is categoryTypeFK mapped?




On Apr 4, 2007, at 8:03 PM, Phill Moran wrote:

 I did a workspace search and it exists in only one place. Also if I 
 comment out the one it complains about it complains about the next 
 one. But only in this java file. I even did an clean and build to make 
 sure there were no old class files hanging out.

 -Original Message-
 From: Dain Sundstrom [mailto:[EMAIL PROTECTED]
 Sent: April 4, 2007 5:06 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: Duplicate Query - where none exists

 I think I saw this once.  The problem is in JPA named queries are all 
 contained in a single global namespace, so if you have to persistent 
 beans that define queries with the same name you get a warning.  It 
 would be nice if the warning told you where the duplicate declarations 
 are located.

 -dain

 On Apr 3, 2007, at 10:07 PM, Phill Moran wrote:

 Anyone seen this before

 WARN   [main] openjpa.MetaData - Found duplicate query StoreFXPK
 in class
 ..  Ignoring.

 This class has only three such named queries all different names and 
 different actual queries. See following @NamedQueries( {
  @NamedQuery(name = StoreFXPK, query = SELECT s FROM Store s
 WHERE
 s.id = :primaryKey),
  @NamedQuery(name = StoreFXTypeAndName, query = SELECT s FROM 
 Store s WHERE s.type = :type AND UPPER(s.name) LIKE :storeName OR
 UPPER(s.displayName) = :storeName2),
  @NamedQuery(name = StoreFXName, query = SELECT s FROM Store s

 WHERE UPPER(s.name) = :storeName OR UPPER(s.displayName) =
 :storeName2)
  })

 I even renamed the duplicate parms to make sure it was not a trickle 
 down exception. Not only that, if I comment out the StoreFXPK query I 
 get the same error on the next named Query. I did a search on the 
 workspace an this is only used in one place (factory class) and 
 define in another (persistent class). I have no doubt this is 
 something I have done but am unsure what it is I get the follow stack 
 trace when executing the following line:

 Query q = em.createNamedQuery(StoreFXName); - not the same query 
 mentioned in the above warning...the plot thickens

 The unmapped field in the stack trace is mapped.

 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:2
 83)
  at
 org.apache.openjpa.meta.MetaDataRepository.getMetaData
 (MetaDataRepository.java:3
 38)
  at

Re: [VOTE] ArgumentException : More parameters were passed to execute() than were declared

2007-04-04 Thread Dain Sundstrom


I tested the fix and it solved my problem.

Thanks,

-dain

On Apr 2, 2007, at 3:00 PM, Marc Prud'hommeaux wrote:


Dain-

On Apr 2, 2007, at 12:23 PM, Dain Sundstrom wrote:


Is this something we can put in 0.9.7 or has that been cut already?


I've gone ahead and committed the fix for this.




-dain

On Apr 1, 2007, at 10:07 PM, Craig L Russell wrote:

+1 to remove the restriction. As long as no parameters are  
missing, the query should be considered sufficient.


Craig

On Apr 1, 2007, at 9:30 AM, Marc Prud'hommeaux wrote:



Seem fair enough to get rid of the description. I've opened  
https://issues.apache.org/jira/browse/OPENJPA-196 describing the  
issue.


+1 from me to remove the restriction that there be exactly as  
many positional parameters declared as were assigned.




On Mar 31, 2007, at 7:32 PM, Dain Sundstrom wrote:

Actually, I think there is a bigger problem...  Say I have a  
query like this:


SELECT x FROM foo AS x WHERE foo.name = ?2

The org.apache.openjpa.kernel.QueryImpl.assertParameters(...)  
code assumes that if I have 1 parameter it is numbered ?1, but  
in EJB 2.1 this was not a requirement and there are  
certification tests that verify you are allowed to have  
unused parameters (e.g, in my example about ?1 and ?N where  
N2 are all not used).  I couldn't find any text in the  
specification that says that all all positional parameters must  
be used in the query, but I did find text that say the EJB-QL  
3.0 language is an extension of the EJB-QL 2.1 language:


The Java Persistence query language is an extension of the  
Enterprise Java Beans query language, EJB QL, definedin[5].


So I think we must remove the extra-params check, but I would  
be happy with a don't check for extra-params flag.


-dain

On Mar 31, 2007, at 8:56 AM, Dain Sundstrom wrote:

I'm working on a CMP 2 implementation that delegates to  
OpenJPA for persistence.  I'm running into a problem where I  
get the following exception:


org.apache.openjpa.persistence.ArgumentException : More  
parameters were passed to execute() than were declared: 4  
parameters were specified for query execution, but only 2  
parameters were declared in the query.



In CMP you declare finder and select methods that have  
parameters which are passed into the query engine.  You can  
have as many parameters as you like but are not required to  
use them all, but it appears that OpenJPA is enforcing a  
restriction where if the EJB-QL text only lists say 2  
parameters and I set 4 I get the above exception.  In order of  
perference:


Is this spec required? If not, can we remove the check?

Is there a way to disable the check?  If so, how?

Is there a way to determine the number of paramters a query  
takes?  If so, I can change my code.


Is there a way to get the ejbql text from a Query object? If  
so, I'll write a quick parser to determine number of queries  
myself.


BTW, I'm currently using 0.9.6.

Thanks,

-dain






Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/ 
products/jdo

408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

RE: Forced getter/setter access

RE: Forced getter/setter access

Re: 0.9.8 release

RE: Duplicate Query - where none exists

Re: why not an EntityExistsException was thrown?

I am interested to join OPENJPA group

Re: why not an EntityExistsException was thrown?

Re: why not an EntityExistsException was thrown?

RE: why not an EntityExistsException was thrown?

RE: I am interested to join OPENJPA group

Re: Duplicate Query - where none exists

JPA Bug:Nesting of Emebedded in Embeddable element

RE: JPA Bug:Nesting of Emebedded in Embeddable element

API or Query hints

[jira] Created: (OPENJPA-199) bulk update gets parsing exception trying to update an attribute of an embedded class

[jira] Updated: (OPENJPA-199) bulk update gets parsing exception trying to update an attribute of an embedded class

[jira] Updated: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS

RE: API or Query hints

[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS

[jira] Created: (OPENJPA-200) cannot use enum type as input parameter for a query, and you cannot specify an Enum type as a literal, this also means that there is no way to update an enum type using j

[jira] Updated: (OPENJPA-200) cannot use enum type as input parameter for a query, and you cannot specify an Enum type as a literal, this also means that there is no way to update an enum type using j

[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS

[jira] Created: (OPENJPA-201) Mapping Tool ignores the @JoinColumn annotation in a @ManyToOne mapping if the table argument is used

[jira] Updated: (OPENJPA-201) Mapping Tool ignores the @JoinColumn annotation in a @ManyToOne mapping if the table argument is used

[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS

[jira] Created: (OPENJPA-202) after invoking LRS processing in a client by calling an @LRS annotated relationship, the next em.clear()/em.close() gets org.apache.openjpa.persistence.InvalidStateExcept

[jira] Updated: (OPENJPA-202) after invoking LRS processing in a client by calling an @LRS annotated relationship, the next em.clear()/em.close() gets org.apache.openjpa.persistence.InvalidStateExcept

RE: Duplicate Query - where none exists

Re: Duplicate Query - where none exists

RE: Duplicate Query - where none exists

Re: [VOTE] ArgumentException : More parameters were passed to execute() than were declared

31 matches

Site Navigation

Mail list logo

Footer information