Hi, I'm a big fan of fetch plan but there is something I don't understand. I have a root class with many link or relation. I'm using annotation and only annotation. Mose of the link are set with EAGER fetching and cascade ALL. This is done so by default, fetch will be eager and action will cascade the attributes. This is the wanted default behavior when no fetch plan is used. I'm using fetch plan to override that behavior when I need it. Unfortunately, because most of the time my relation are eagerly fetched by default it may have hidden bad behavior or bug to me. When I use fetch plan to add some field to retrieve tham, it works but maybe due to the default behavior I have specified in the annotation. However I had tested to add to fetch plan an attribute that was not eagerly retreived and it had worked when I was discovering the OpenJPA API. The question come now : how to dynamically, using fetch plan, exclude (rather than adding) to the fetch plan some attribute not to retrieve ? It is something to override my default definition of fetching in the annotation. I found the method fetplan.removeField(...) is it the right one to use to exclude an attribute from being processed (whatever it will be updated, read, ...) ? Can that be mixed in the fetch plan : removeField and addField ? To speed up the code is there a way to exclude all attributes before adding the few I want to add ? It would be quicker and simpler than having to remove one by one the field I didn't added. fetplan.removeAllFields(Class) and the other way around : fetplan.addAllFields(Class) Thanks !
it work as you said, a second request is needed.
Thanks !
On Dec 3, 2009, at 15:55 , Rick Curtis wrote:
> When you call cc.merge(ooo); any changes made to that instance while it was
> detached will be persisted to the DB.
>
> I assume your comment "Here I modify the ooo but I want this modif to be
> persist, not the other one before" means that you only want the changes from
> after the tran begins to be persistent... If that assumption is correct,
> you'll need to get a new instance of ooo to make the changes on.
> --
> Thanks,
> Rick
>
> On Thu, Dec 3, 2009 at 8:49 AM, Jean-Baptiste BRIAUD -- Novlog <
> j-b.briaud@novlog.com> wrote:
>
>> Hi the list,
>>
>> Am i right on the following pseudo code ?
>>
>> // Note the detach.
>> // getFullById come back with an instance of MyObject from the
>> primary key
>> final MyObject ooo = detach(getFullById(cc....
>>
>> < Here I modify (a lot) ooo but don't wan't the modif to be
>> persist>
>>
>> try {
>> cc.beginTransaction();
>>
>> <Here I modify the ooo but I want this modif to be
>> persist, not the other one before>
>>
>> cc.merge(ooo);
>> cc.commitTransaction();
>>
>> } catch (...) {
>> cc.rollbackTransaction();
>> }
>>
>> Thanks !
In Hibernate and JPA, I'm used to looking at scenarios where I map a single table to a single entity, along with relationships to other entities with various multiplicities. I'm now looking at a situation where I'm going to need to develop a JPA mapping for a pretty large collection of entities, where the largest entities actually are defined by an aggregation of numerous tables (like 20). What provisions are there in JPA and OpenJPA for mapping multiple tables to a single entity? I'm not talking about an inheritance hierarchy, but where the numerous tables are linked by a common PK value.
> -----Original Message----- > From: Michael Dick [mailto:michael.d.dick@gmail.com] > Sent: Friday, December 04, 2009 1:54 PM > To: users@openjpa.apache.org > Subject: Re: Why does the enhancer create a PROTECTE no-args > constructor by default? > > Hi David, > > The JVM will create a no-arg constructor if you have no other > constructors. > The spec requires a no-arg constructor so that the persistence provider > can > create an empty instance. OpenJPA uses it via some tricky generated > code > (bytecode insertion). > > As for why it's protected instead of public I presume the original devs > thought it was safer to restrict access to the generated constructor. > It > isn't documented in the manual, but you could go diving in > PCEnhancer.java > (which generates the constructor) and see if there are any comments > that > shed some light on the rationale. Nope, not a word. The "enhanceClass()" generates the constructor as public if it's externalizable, private if it's final (which is odd, as I thought you couldn't have final persistent classes), and protected otherwise. No indication why. There was a comment about making it public if the class was externalizable, but nothing else. > On Fri, Dec 4, 2009 at 2:55 PM, KARR, DAVID (ATTCINW) > <dk068x@att.com>wrote: > > > > -----Original Message----- > > > From: Rick Curtis [mailto:curtisr7@gmail.com] > > > Sent: Friday, December 04, 2009 12:31 PM > > > To: users@openjpa.apache.org > > > Subject: Re: Why does the enhancer create a PROTECTE no-args > > > constructor by default? > > > > > > David- > > > > > > Per the JPA spec -- > > > > > > The entity class must have a no-arg constructor. The entity class > may > > > have > > > other constructors as well. > > > The no-arg constructor must be public or protected. > > > > > > ...so if your Entity doesn't have one, OpenJPA will do it for you. > > > > Ok, I'll phrase the question again, and perhaps I can make it more > > obvious this time. > > > > Why does the enhancer create a PROTECTED no-args constructor, and not > a > > PUBLIC one? > > > > If it was going to create a PUBLIC constructor, there'd be absolutely > no > > point to this, because that's exactly what the JVM does. If the > > enhancer had a good reason to create a PROTECTED constructor instead > of > > a PUBLIC one, then I can see why the enhancer would do this, but I > still > > see no obvious reason to create a PROTECTED constructor. > > > > Is that clearer now? > > > > > > -- > > > Thanks, > > > Rick > > > > > > On Fri, Dec 4, 2009 at 1:29 PM, KARR, DAVID (ATTCINW) > > > <dk068x@att.com>wrote: > > > > > > > I'm reading the OpenJPA doc, and I see that the enhancer creates > a > > > > protected no-args constructor if there is no public one. Why > > exactly > > > > does it do that? What is the point of creating a protected > > > constructor > > > > instead of letting the JVM create the public one? The doc only > says > > > > that it does this, not why. > > > > > >
Hi David, The JVM will create a no-arg constructor if you have no other constructors. The spec requires a no-arg constructor so that the persistence provider can create an empty instance. OpenJPA uses it via some tricky generated code (bytecode insertion). As for why it's protected instead of public I presume the original devs thought it was safer to restrict access to the generated constructor. It isn't documented in the manual, but you could go diving in PCEnhancer.java (which generates the constructor) and see if there are any comments that shed some light on the rationale. -mike On Fri, Dec 4, 2009 at 2:55 PM, KARR, DAVID (ATTCINW) <dk068x@att.com>wrote: > > -----Original Message----- > > From: Rick Curtis [mailto:curtisr7@gmail.com] > > Sent: Friday, December 04, 2009 12:31 PM > > To: users@openjpa.apache.org > > Subject: Re: Why does the enhancer create a PROTECTE no-args > > constructor by default? > > > > David- > > > > Per the JPA spec -- > > > > The entity class must have a no-arg constructor. The entity class may > > have > > other constructors as well. > > The no-arg constructor must be public or protected. > > > > ...so if your Entity doesn't have one, OpenJPA will do it for you. > > Ok, I'll phrase the question again, and perhaps I can make it more > obvious this time. > > Why does the enhancer create a PROTECTED no-args constructor, and not a > PUBLIC one? > > If it was going to create a PUBLIC constructor, there'd be absolutely no > point to this, because that's exactly what the JVM does. If the > enhancer had a good reason to create a PROTECTED constructor instead of > a PUBLIC one, then I can see why the enhancer would do this, but I still > see no obvious reason to create a PROTECTED constructor. > > Is that clearer now? > > > -- > > Thanks, > > Rick > > > > On Fri, Dec 4, 2009 at 1:29 PM, KARR, DAVID (ATTCINW) > > <dk068x@att.com>wrote: > > > > > I'm reading the OpenJPA doc, and I see that the enhancer creates a > > > protected no-args constructor if there is no public one. Why > exactly > > > does it do that? What is the point of creating a protected > > constructor > > > instead of letting the JVM create the public one? The doc only says > > > that it does this, not why. > > > >
I noticed in the doc that OpenJPA doesn't support storing or retrieving the timezone value, just the Date portion, even for a TIMESTAMPTZ column (although it doesn't mention that last part). The doc for EclipseLink says something similar, but it simply says that you have to use "native SQL" in order to get/set the timezone with Calendar. I can't imagine any reason why native queries in EclipseLink would be able to do this, but native queries in OpenJPA couldn't. Is there a good reason why a statement to this effect didn't make it into the OpenJPA doc (besides "we didn't think of it")?
> -----Original Message----- > From: Rick Curtis [mailto:curtisr7@gmail.com] > Sent: Friday, December 04, 2009 12:31 PM > To: users@openjpa.apache.org > Subject: Re: Why does the enhancer create a PROTECTE no-args > constructor by default? > > David- > > Per the JPA spec -- > > The entity class must have a no-arg constructor. The entity class may > have > other constructors as well. > The no-arg constructor must be public or protected. > > ...so if your Entity doesn't have one, OpenJPA will do it for you. Ok, I'll phrase the question again, and perhaps I can make it more obvious this time. Why does the enhancer create a PROTECTED no-args constructor, and not a PUBLIC one? If it was going to create a PUBLIC constructor, there'd be absolutely no point to this, because that's exactly what the JVM does. If the enhancer had a good reason to create a PROTECTED constructor instead of a PUBLIC one, then I can see why the enhancer would do this, but I still see no obvious reason to create a PROTECTED constructor. Is that clearer now? > -- > Thanks, > Rick > > On Fri, Dec 4, 2009 at 1:29 PM, KARR, DAVID (ATTCINW) > <dk068x@att.com>wrote: > > > I'm reading the OpenJPA doc, and I see that the enhancer creates a > > protected no-args constructor if there is no public one. Why exactly > > does it do that? What is the point of creating a protected > constructor > > instead of letting the JVM create the public one? The doc only says > > that it does this, not why. > >
David- Per the JPA spec -- The entity class must have a no-arg constructor. The entity class may have other constructors as well. The no-arg constructor must be public or protected. ...so if your Entity doesn't have one, OpenJPA will do it for you. -- Thanks, Rick On Fri, Dec 4, 2009 at 1:29 PM, KARR, DAVID (ATTCINW) <dk068x@att.com>wrote: > I'm reading the OpenJPA doc, and I see that the enhancer creates a > protected no-args constructor if there is no public one. Why exactly > does it do that? What is the point of creating a protected constructor > instead of letting the JVM create the public one? The doc only says > that it does this, not why. >
I'm reading the OpenJPA doc, and I see that the enhancer creates a protected no-args constructor if there is no public one. Why exactly does it do that? What is the point of creating a protected constructor instead of letting the JVM create the public one? The doc only says that it does this, not why.
Hi,
Kind of strange. OpenJPA has many, many examples of persistent operations
against various databases, including MySQL. All without the behavior that
you are seeing. A couple of things jump out at me...
o How is your dao constructor setting the values on the fields? Since you
are using property-based access, all access to these fields need to be
through the getter/setter methods.
o I noticed that your getter/setter methods are "synchronized final".
OpenJPA states support for "final" methods, so that should work okay. But,
why are you using synchronized? I don't see why this should make a
difference, but it's overhead that should not be necessary.
o And, when is the transaction completing? The em.persist() method does
not push items to the database. The enclosing transaction needs to
complete, or a flush needs to happen, to push the data to the database.
o How are you verifying that the records are getting created? You see
actual records (rows) getting created with new generated IDs, but none of
the other fields are filled in? You could turn on SQL trace from OpenJPA
and see what SQL is actually being generated. This would help confirm
whether the problem is in the application space or the database space.
Let's start with these questions before going further.
Thanks,
Kevin
On Fri, Dec 4, 2009 at 9:32 AM, kpsuk <keithsecker@yahoo.co.uk> wrote:
>
> Having a little trouble with openJPA persiting with MySQL, whilst new rows
> are being created for each em.persist(dao) the rows are bring populated
> with
> 'NULL' values for each column!
>
> I get no error in my logs and debugging shows that the property values are
> there right upto the em.persist(dao) line of code.
>
> DAO
> @Entity
> @Table(name = "tbl_user_details")
> public class UserRegistrationDao implements java.io.Serializable {
> private int id;
> private String firstname;
> private String surname;
> private String email;
> @Id
> @GeneratedValue(strategy = GenerationType.IDENTITY)
> @Column(name="id")
> public int getId() {
> return this.id;
> }
> public void setId(int id) {
> this.id = id;
> }
>
> @Basic
> @Column(name="firstname")
> public synchronized final String getFirstname() {
> return this.firstname;
> }
> public synchronized final void setFirstname(String firstname) {
> this.firstname = firstname;
> }
>
> @Basic
> @Column(name="surname")
> public synchronized final String getSurname() {
> return this.surname;
> }
> public synchronized final void setSurname(String surname) {
> this.surname = surname;
> }
>
> @Basic
> @Column(name="email")
> public synchronized final String getEmail() {
> return this.email;
> }
> public synchronized final void setEmail(String email) {
> this.email = email;
> }
> }
>
> Bean
> @PersistenceContext(unitName = "users", type =
> PersistenceContextType.EXTENDED)
> private EntityManager _em;
> @Override
> public boolean create(Map<String, Object> args) {
> UserRegistrationDao dao = new UserRegistrationDao(args);
> _em.persist(dao); // *** upto here values are present ***
>
>
> persistence.xml
>
> <persistence-unit name="users" transaction-type="JTA">
>
> <provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
> <jta-data-source>jdbc/users</jta-data-source>
> <!-- Enumerate your persistent classes here. -->
> <class>com.project1.business.dao.UserRegistrationDao</class>
>
> <properties>
> <property name="openjpa.ConnectionURL"
> value="jdbc:mysql://localhost:3306/users"/>
> <property name="openjpa.ConnectionDriverName"
> value="com.mysql.jdbc.Driver"/>
> <property name="openjpa.ConnectionUserName"
> value="root"/>
> <property name="openjpa.ConnectionPassword"
> value="rootpass123"/>
> </properties>
>
> </persistence-unit>
>
> --
> View this message in context:
> http://n2.nabble.com/openJPA-with-EJB3-MySQL-on-WAS7-tp4113103p4113103.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
Just a quick question. Is the table already created or are you trying to use OpenJPA to create
the table?
-----Original Message-----
From: kpsuk [mailto:keithsecker@yahoo.co.uk]
Sent: Friday, December 04, 2009 9:32 AM
To: users@openjpa.apache.org
Subject: openJPA with EJB3 MySQL on WAS7
Having a little trouble with openJPA persiting with MySQL, whilst new rows
are being created for each em.persist(dao) the rows are bring populated with
'NULL' values for each column!
I get no error in my logs and debugging shows that the property values are
there right upto the em.persist(dao) line of code.
DAO
@Entity
@Table(name = "tbl_user_details")
public class UserRegistrationDao implements java.io.Serializable {
private int id;
private String firstname;
private String surname;
private String email;
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(name="id")
public int getId() {
return this.id;
}
public void setId(int id) {
this.id = id;
}
@Basic
@Column(name="firstname")
public synchronized final String getFirstname() {
return this.firstname;
}
public synchronized final void setFirstname(String firstname) {
this.firstname = firstname;
}
@Basic
@Column(name="surname")
public synchronized final String getSurname() {
return this.surname;
}
public synchronized final void setSurname(String surname) {
this.surname = surname;
}
@Basic
@Column(name="email")
public synchronized final String getEmail() {
return this.email;
}
public synchronized final void setEmail(String email) {
this.email = email;
}
}
Bean
@PersistenceContext(unitName = "users", type =
PersistenceContextType.EXTENDED)
private EntityManager _em;
@Override
public boolean create(Map<String, Object> args) {
UserRegistrationDao dao = new UserRegistrationDao(args);
_em.persist(dao); // *** upto here values are present ***
persistence.xml
<persistence-unit name="users" transaction-type="JTA">
<provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
<jta-data-source>jdbc/users</jta-data-source>
<!-- Enumerate your persistent classes here. -->
<class>com.project1.business.dao.UserRegistrationDao</class>
<properties>
<property name="openjpa.ConnectionURL"
value="jdbc:mysql://localhost:3306/users"/>
<property name="openjpa.ConnectionDriverName"
value="com.mysql.jdbc.Driver"/>
<property name="openjpa.ConnectionUserName" value="root"/>
<property name="openjpa.ConnectionPassword" value="rootpass123"/>
</properties>
</persistence-unit>
--
View this message in context: http://n2.nabble.com/openJPA-with-EJB3-MySQL-on-WAS7-tp4113103p4113103.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Tao -
Can you post a simple testcase demonstrating the problem?
--
Thanks,
Rick
On Thu, Dec 3, 2009 at 3:38 PM, Javatao <taolu2000@gmail.com> wrote:
>
> Hi, Experts,
>
> I am having an issue with detached object in OpenJPA.
>
> Setter method of relationship field does not work.
> Setter method of primitive field works fine.
>
> Here is an example
> =======================================
> ...
> Foo foo = entityManager.find(Foo.class, 1);
> Bar foo = entityManager.find(Bar.class, 2);
> ...
> entityManager.close();
> ...
>
>
> foo.setName("newNameFoo");
> bar.setName("newNameBar");
> foo.setBar(bar);
> System.out.println(foo.getName());
> System.out.println(bar.getName());
> System.out.println(foo.getBar());
> =====================
>
> Here is the output:
>
> newNameFoo
> newNameBar
> null
>
>
> This is so wierd!
>
> Any idea?
>
> Many thanks in advance!
>
> Tao
>
>
> --
> View this message in context:
> http://n2.nabble.com/Setter-not-working-for-detached-object-tp4109048p4109048.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
Having a little trouble with openJPA persiting with MySQL, whilst new rows
are being created for each em.persist(dao) the rows are bring populated with
'NULL' values for each column!
I get no error in my logs and debugging shows that the property values are
there right upto the em.persist(dao) line of code.
DAO
@Entity
@Table(name = "tbl_user_details")
public class UserRegistrationDao implements java.io.Serializable {
private int id;
private String firstname;
private String surname;
private String email;
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(name="id")
public int getId() {
return this.id;
}
public void setId(int id) {
this.id = id;
}
@Basic
@Column(name="firstname")
public synchronized final String getFirstname() {
return this.firstname;
}
public synchronized final void setFirstname(String firstname) {
this.firstname = firstname;
}
@Basic
@Column(name="surname")
public synchronized final String getSurname() {
return this.surname;
}
public synchronized final void setSurname(String surname) {
this.surname = surname;
}
@Basic
@Column(name="email")
public synchronized final String getEmail() {
return this.email;
}
public synchronized final void setEmail(String email) {
this.email = email;
}
}
Bean
@PersistenceContext(unitName = "users", type =
PersistenceContextType.EXTENDED)
private EntityManager _em;
@Override
public boolean create(Map<String, Object> args) {
UserRegistrationDao dao = new UserRegistrationDao(args);
_em.persist(dao); // *** upto here values are present ***
persistence.xml
<persistence-unit name="users" transaction-type="JTA">
<provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
<jta-data-source>jdbc/users</jta-data-source>
<!-- Enumerate your persistent classes here. -->
<class>com.project1.business.dao.UserRegistrationDao</class>
<properties>
<property name="openjpa.ConnectionURL"
value="jdbc:mysql://localhost:3306/users"/>
<property name="openjpa.ConnectionDriverName"
value="com.mysql.jdbc.Driver"/>
<property name="openjpa.ConnectionUserName" value="root"/>
<property name="openjpa.ConnectionPassword" value="rootpass123"/>
</properties>
</persistence-unit>
--
View this message in context: http://n2.nabble.com/openJPA-with-EJB3-MySQL-on-WAS7-tp4113103p4113103.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
On Fri, Dec 4, 2009 at 3:40 AM, Srinivasan Krishnamoorthy < srinivasan.krish@live.com> wrote: > > Hi Daryl, > Did you get a solution to this problem... We are also facing exactly the > same issue.. > > No, my work around was to not use fetch plans and use "left join fetch" in my query. I posted my unit test here but it seems no one took an interest. When I get a chance I'll post it to the dev list. My unit test is not as simple as I'd like it to be. Perhaps you can produce a unit test that is simpler. -- Daryl Stultz _____________________________________ 6 Degrees Software and Consulting, Inc. http://www.6degrees.com mailto:daryl@6degrees.com
Hi Daryl,
Did you get a solution to this problem... We are also facing exactly the
same issue..
My query is something like..
"select DISTINCT o from Organisation o where o.typeFlag=0 and o.name like
:name".
The entity Organisation shares many OneToMany relations with other entities.
(some are self-referencing).
Am not able to figure out whats the problem..
I get the below exception trace..
Caused by: java.lang.ArrayIndexOutOfBoundsException: Array index out of
range: 3
at
org.apache.openjpa.meta.ClassMetaData.getExtraFieldDataIndex(ClassMetaData.java:860)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:358)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:278)
at
com.ibm.ws.persistence.jdbc.kernel.WsJpaJDBCStoreManager.initialize(WsJpaJDBCStoreManager.java:144)
at
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
at
org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:894)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852)
I am using DB2 v 9.1.
Best Regards,
Srinivasan Krishnamoorthy.
Daryl Stultz wrote:
>
> Hello, I'm getting the following:
>
> java.lang.ArrayIndexOutOfBoundsException: 2
> at
> org.apache.openjpa.meta.ClassMetaData.getExtraFieldDataIndex(ClassMetaData.java:859)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:358)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:278)
> at
> org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
> at
> org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
> at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:894)
> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852)
> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:774)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:982)
> at
> org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:278)
> at
> org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(SelectImpl.java:2400)
> at
> org.apache.openjpa.jdbc.meta.strats.RelationFieldStrategy.loadEagerJoin(RelationFieldStrategy.java:541)
> at
> org.apache.openjpa.jdbc.meta.FieldMapping.loadEagerJoin(FieldMapping.java:807)--
>
>
> I've attached a unit test that exposes it. I've done my best to pare
> things
> down but it seems anything else I remove makes it go away (there are
> several
> things that could be removed to make it go away). The unit test passes
> when
> the exception is thrown.
>
> In short, this works:
>
> Query query = em.createQuery("select o from Case as o" +
> " left join fetch o.scheduledAssignments" +
> " where o.scheduleDay = :sd");
> query.setParameter("sd", sd);
> List<Case> allCases = query.getResultList();
>
> But this doesn't:
>
> Query query = em.createQuery("select o from Case as o" +
> " where o.scheduleDay = :sd");
> query.setParameter("sd", sd);
> FetchPlan fetchPlan = ((QueryImpl) query).getFetchPlan();
> fetchPlan.addField(Case.class, "scheduledAssignments");
> List<Case> allCases = query.getResultList();
>
> The test case runs against PostgreSQL. I would really appreciate it if
> someone could verify the test passes under some other database or if it
> fails, under PostgreSQL. Of course it would be even better if an OpenJPA
> expert could find the problem.
>
> I will also accept suggestions for building a better unit test package.
>
> Thanks for your help.
>
> Daryl Stultz
> _____________________________________
> 6 Degrees Software and Consulting, Inc.
> http://www.6degrees.com
> mailto:daryl@6degrees.com
>
>
>
--
View this message in context: http://n2.nabble.com/Out-of-bounds-exception-with-fetch-plan-tp4028405p4111206.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Hi Daryl,
Did you get a solution to this problem... We are also facing exactly the
same issue..
My query is something like..
"select DISTINCT o from Organisation o where o.typeFlag=0 and o.name like
:name".
The entity Organisation shares many OneToMany relations with other entities.
(some are self-referencing).
Am not able to figure out whats the problem..
I get the below exception trace..
Caused by: java.lang.ArrayIndexOutOfBoundsException: Array index out of
range: 3
at
org.apache.openjpa.meta.ClassMetaData.getExtraFieldDataIndex(ClassMetaData.java:860)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:358)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:278)
at
com.ibm.ws.persistence.jdbc.kernel.WsJpaJDBCStoreManager.initialize(WsJpaJDBCStoreManager.java:144)
at
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
at
org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:894)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852)
I am using DB2 v 9.1.
Best Regards,
Srinivasan Krishnamoorthy.
Daryl Stultz wrote:
>
> Hello, I'm getting the following:
>
> java.lang.ArrayIndexOutOfBoundsException: 2
> at
> org.apache.openjpa.meta.ClassMetaData.getExtraFieldDataIndex(ClassMetaData.java:859)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:358)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:278)
> at
> org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
> at
> org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
> at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:894)
> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852)
> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:774)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:982)
> at
> org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:278)
> at
> org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(SelectImpl.java:2400)
> at
> org.apache.openjpa.jdbc.meta.strats.RelationFieldStrategy.loadEagerJoin(RelationFieldStrategy.java:541)
> at
> org.apache.openjpa.jdbc.meta.FieldMapping.loadEagerJoin(FieldMapping.java:807)--
>
>
> I've attached a unit test that exposes it. I've done my best to pare
> things
> down but it seems anything else I remove makes it go away (there are
> several
> things that could be removed to make it go away). The unit test passes
> when
> the exception is thrown.
>
> In short, this works:
>
> Query query = em.createQuery("select o from Case as o" +
> " left join fetch o.scheduledAssignments" +
> " where o.scheduleDay = :sd");
> query.setParameter("sd", sd);
> List<Case> allCases = query.getResultList();
>
> But this doesn't:
>
> Query query = em.createQuery("select o from Case as o" +
> " where o.scheduleDay = :sd");
> query.setParameter("sd", sd);
> FetchPlan fetchPlan = ((QueryImpl) query).getFetchPlan();
> fetchPlan.addField(Case.class, "scheduledAssignments");
> List<Case> allCases = query.getResultList();
>
> The test case runs against PostgreSQL. I would really appreciate it if
> someone could verify the test passes under some other database or if it
> fails, under PostgreSQL. Of course it would be even better if an OpenJPA
> expert could find the problem.
>
> I will also accept suggestions for building a better unit test package.
>
> Thanks for your help.
>
> Daryl Stultz
> _____________________________________
> 6 Degrees Software and Consulting, Inc.
> http://www.6degrees.com
> mailto:daryl@6degrees.com
>
>
>
--
View this message in context: http://n2.nabble.com/Out-of-bounds-exception-with-fetch-plan-tp4028405p4111204.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Hi,
JPA makes me mad these days ;-) I have a simple DAO which might produce invalid JPAQL.
@Repository
@Transactional
public class MetaDataDaoImpl implements MetaDataDao {
public Object getClientMetaDataByObjName(String objname, long client) {
Query query = em.createQuery("select x from " + objname + " x where x.client = "
+ client);
Object o;
try {
o = query.getSingleResult();
} catch (Exception e) {
return null;
}
return o;
}
}
There are cases where "objname" is an invalid identifier and i cant prevent this. So i thought
i just return null in this case. Of course i am getting the expected org.apache.openjpa.persistence.ArgumentException
in the try block.
So i get into the catch block and the CALLER should proceed, but in fact, when leaving this
method, the CALLER never gets the chance to proceed because of the exception below.
First of all i dont know why he want to commit() something in a method where i dont modify
any object. In fact i dont even get an object back which i could change. I also tried "read
only" with a seperate Transaction attribute on the method and i also tried a REQUIRES_NEW,
just to be sure that i am not wihin a larger transaction block, which i am not.
When i move the try catch block to the caller and throwing the exeption from the DAO, i can
proceed and ignore the stuff in the caller. But why doesnt it work the way i ve done it?
---
javax.servlet.ServletException: org.springframework.orm.jpa.JpaSystemException: The transaction
cannot be committed, because it was already marked for rollback only. The transaction will
be rolled back instead. The cause of the rollback-only status is reported in the embedded
stack.; nested exception is org.apache.openjpa.persistence.PersistenceException: The transaction
cannot be committed, because it was already marked for rollback only. The transaction will
be rolled back instead. The cause of the rollback-only status is reported in the embedded
stack. at org.apache.struts.action.RequestProcessor.processException(RequestProcessor.java:520)
at com.cc.framework.adapter.struts.FWRequestProcessor.processActionPerform(Unknown Source)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:228) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:462) at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at de.netversys.util.filter.CheckSessionFilter.doFilter(CheckSessionFilter.java:50) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619)
Caused by: org.springframework.orm.jpa.JpaSystemException: The transaction cannot be committed,
because it was already marked for rollback only. The transaction will be rolled back instead.
The cause of the rollback-only status is reported in the embedded stack.; nested exception
is org.apache.openjpa.persistence.PersistenceException: The transaction cannot be committed,
because it was already marked for rollback only. The transaction will be rolled back instead.
The cause of the rollback-only status is reported in the embedded stack. at org.springframework.orm.jpa.EntityManagerFactoryUtils.convertJpaAccessExceptionIfPossible(EntityManagerFactoryUtils.java:296)
at org.springframework.orm.jpa.DefaultJpaDialect.translateExceptionIfPossible(DefaultJpaDialect.java:120)
at org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactionManager.java:460)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy12.getClientMetaDataByObjName(Unknown Source) at de.netversys.process.AbstractProductEvaluator.getBasicClientMetaData(AbstractProductEvaluator.java:108)
at de.netversys.process.PossibleProductsEvaluator.getPossibleProducts(PossibleProductsEvaluator.java:119)
at de.netversys.action.frontend.DoWeightingAction.doExecute(DoWeightingAction.java:183) at
de.netversys.action.frontend.FrontendAction.execute(FrontendAction.java:63) at de.logentis.struts.DelegatingActionProxy.execute(DelegatingActionProxy.java:105)
at com.cc.framework.adapter.struts.RequestProcessorUtil.processAction(Unknown Source) ...
25 more Caused by: org.apache.openjpa.persistence.PersistenceException: The transaction cannot
be committed, because it was already marked for rollback only. The transaction will be rolled
back instead. The cause of the rollback-only status is reported in the embedded stack. at
org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:89) at org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1350)
at org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:877) at org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:512)
at org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactionManager.java:456)
... 38 more Caused by: org.apache.openjpa.persistence.ArgumentException: An error occurred
while parsing the query filter "select x from MdExekutiveTransport x where x.client = 50".
Error message: The name "MdExekutiveTransport" is not a recognized entity or identifier. Perhaps
you meant MdSeurDefault, which is a close match. Known entity names: [User, CarrierMapping,]
at org.apache.openjpa.kernel.exps.AbstractExpressionBuilder.parseException(AbstractExpressionBuilder.java:118)
at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpressionBuilder.java:177)
at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaData(JPQLExpressionBuilder.java:150)
at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:225)
at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:195)
at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JPQLExpressionBuilder.java:188)
at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$600(JPQLExpressionBuilder.java:69)
at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate(JPQLExpressionBuilder.java:1756)
at org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:56) at org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(ExpressionStoreQuery.java:153)
at org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:658) at org.apache.openjpa.kernel.QueryImpl.compilationFromCache(QueryImpl.java:639)
at org.apache.openjpa.kernel.QueryImpl.compileForCompilation(QueryImpl.java:605) at org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:667)
at org.apache.openjpa.kernel.QueryImpl.getOperation(QueryImpl.java:1492) at org.apache.openjpa.kernel.DelegatingQuery.getOperation(DelegatingQuery.java:123)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:243) at org.apache.openjpa.persistence.QueryImpl.getSingleResult(QueryImpl.java:316)
at de.netversys.dao.impl.MetaDataDaoImpl.getClientMetaDataByObjName(MetaDataDaoImpl.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at
java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106)
... 34 more
--
Marc Logemann - LOGENTIS GmbH
geschäftsführender Gesellschafter
Westerbreite 7 - 49084 Osnabrück
Tel. +49 (0)541 - 80049791
Fax +49 (0)541 - 9778172
Mob. +49 (0)177 - 8220182
http://www.logentis.de
ml@logentis.de
*** Enterprise Versandlogistik: http://www.netversys.de
Sitz der Gesellschaft: Osnabrück | Geschäftsführer: Marc Logemann | Handelsregisternummer:
Amtsgericht Osnabrück, HRB 201057 | UstIdNr: DE 814858920
Hi,
i found out that some one-to-one relations in the Superclass added some heavy performance
penalties. I ve not seen it in the SQL logs though. Perhaps i missed it.
Cant comment on the detachment. It seems that its not the problem at all in my case.
---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de
Am 03.12.2009 um 14:53 schrieb Rick Curtis:
> Marc -
>
> In the case where you call em.find(...) and it takes 500ms how long does
> that operation take if the result doesn't need to be detached? The reason I
> ask is that I've been doing some performance work and we found that in some
> instances we are spending way too much time detaching Entities.
>
> --
> Thanks,
> Rick
>
> On Thu, Dec 3, 2009 at 6:06 AM, Marc Logemann <li@logemann.org> wrote:
>
>> Hi,
>>
>> i am facing some weird performance issues. Given this JPA Query:
>>
>> public class SomeDao {
>> @SuppressWarnings("unchecked")
>> public Object getMetaData(Foo.class, long oid) {
>> Object o = em.find(clazz, client);
>> return o;
>> }
>> ..
>> }
>>
>>
>> @Entity
>> @VersionColumn(name = "jpaversion")
>> @Table(name = "foo")
>> public class Foo extends BasicClientMetaData {
>>
>> @Id
>> @Column(name = "client_oid")
>> private long client;
>> ...
>> }
>>
>> @MappedSuperclass
>> public class BasicClientMetaData implements MinMaxWeightAware {
>>
>>
>> @Column(name = "custnr")
>> private String customerNumber;
>>
>> @Column(name = "maxweight")
>> private float maxWeightStandard;
>> ..
>> }
>>
>> When i call the getMetaData() of SomeDao.class (which is transactional and
>> gets detached when its returned to the caller), i measured 500ms for this
>> operation. The underlying SQL only consumes 20ms which i checked by setting
>> the SQL log level to TRACE.
>>
>> Why is there such a difference? I mean, detaching cant be such an issue
>> from performance perspective. I only have this issue with exactly these kind
>> of classes (children of BasicClientMetaData).
>>
>> But i also have other classes which have the @MappedSuperclass which work
>> without performance problems. Does anyone have a hint where i can look out
>> for?
>>
>>
>> thanks.
>>
>> ---
>> regards
>> Marc Logemann
>> http://www.logemann.org
>> http://www.logentis.de
>>
>>
>>
>>
>>
Hi, Experts,
I am having an issue with detached object in OpenJPA.
Setter method of relationship field does not work.
Setter method of primitive field works fine.
Here is an example
=======================================
...
Foo foo = entityManager.find(Foo.class, 1);
Bar foo = entityManager.find(Bar.class, 2);
...
entityManager.close();
...
foo.setName("newNameFoo");
bar.setName("newNameBar");
foo.setBar(bar);
System.out.println(foo.getName());
System.out.println(bar.getName());
System.out.println(foo.getBar());
=====================
Here is the output:
newNameFoo
newNameBar
null
This is so wierd!
Any idea?
Many thanks in advance!
Tao
--
View this message in context: http://n2.nabble.com/Setter-not-working-for-detached-object-tp4109048p4109048.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
> -----Original Message-----
> From: Kevin Sutter [mailto:kwsutter@gmail.com]
> Sent: Thursday, December 03, 2009 11:27 AM
> To: users@openjpa.apache.org
> Subject: Re: What happens with invalid query hints?
>
> Yep, I think we're all in agreement on how we should process these
> hints.
> But, the point of the original posting was that the documentation
> doesn't
> explain this very well. So, we still need a JIRA to get this cleaned
> up.
> Agree?
Although I had volunteered to create the JIRA, now that there's a great
deal more information about this, I'd say someone else would be more
appropriate for that.
> Kevin
>
> On Thu, Dec 3, 2009 at 12:25 PM, Pinaki Poddar <ppoddar@apache.org>
> wrote:
>
> >
> > Craig is right.
> >
> > OpenJPA categories a hint key in the following categories (from
> JavaDoc on
> > HintHandler)
> > * 1. Supported: A key is known to this receiver as collected from
> > different
> > * parts of the system. The value of a supported key is recorded
> and
> > * available via {@link #getHints()} method.
> > * 2. Recognized: A key is not known to this receiver but has a
> prefix
> > which
> > * is known to this receiver. The value of a recognized key is
> not
> > recorded
> > * but its value is available via {@link
> > FetchConfiguration#getHint(String)}
> > * 3. Unrecognized: A key is neither supported nor recognized. The
> value
> > of
> > a
> > * unrecognized key is neither recorded nor set anywhere.
> >
> > Semantically, this categorization aligns with Craig's classification
> as
> > Craig's category 1 = Supported
> > Craig's category 2 = Unrecognized
> > Craig's category 3 = Recognized
> >
> > The runtime exception handling behavior is somewhat more lenient
than
> what
> > Craig describes. None of the three categories of hint key raises an
> > exception. Recognized key is not recorded i.e. they do not appear in
> > getHints() list. They only generate a warning message. The only
> exception
> > scenario is a Supported key supplied with an incompatiable value.
> >
> >
> >
> > Craig L Russell wrote:
> > >
> > > The specification offers this explanation (3.8.9 in the draft
> > > specification dated 2009-10-06):
> > >
> > > Vendors are permitted to support the use of additional, vendor-
> > > specific locking hints. Vendor-specific
> > > hints must not use the javax.persistence namespace.
Vendor-specific
> > > hints must be ignored if
> > > they are not understood.
> > >
> > > So the model is that there are three categories of hints:
> > >
> > > 1. hints that are known to OpenJPA, which are hints defined by the
> > > standard plus the hints that are defined by OpenJPA to extend the
> > > standard hints. These hints are defined in the OpenJPA name space
> > > "openjpa.hint.*" or in the standard hint name space
> > > "javax.persistence.*"
> > >
> > > 2. hints that are defined by other vendors in their own name
space.
> > >
> > > 3. hints that are in the OpenJPA name space but are not known to
> > > OpenJPA. These are usually typos by the user. For example,
> > > "openjpa.hint.OOptimizeResultCount".
> > >
> > > Category 1 hints are honored if possible (e.g. the database in use
> > > supports the hint).
> > >
> > > Category 2 hints are ignored by OpenJPA. This allows you to use
the
> > > same set of hints in a program with different persistence vendors.
> > >
> > > Category 3 hints result in an exception. Typos should be caught
and
> > > reported.
> > >
> > > Sometimes we developers assume that users read and understand the
> > > specification along with the OpenJPA user documentation. Bad
> assumption.
> > >
> > > By the way, this model for hints follows the general model for
> > > properties in several JCP specifications.
> > >
> > > Craig
> > >
> > > On Dec 2, 2009, at 3:55 PM, Kevin Sutter wrote:
> > >
> > >> :-) Yeah, that's kind of confusing, isn't it? I'm assuming that
> it
> > >> should
> > >> read as follows:
> > >>
> > >> "Hints which can not be processed by a particular database are
> > >> ignored.
> > >> Otherwise, invalid hints will result in an ArgumentException
being
> > >> thrown."
> > >>
> > >> OpenJPA has defined certain hints (and JPA 2.0 has defined some
> some
> > >> hints)
> > >> that could be used with Queries. Some of these hints do not
apply
> > >> to all
> > >> databases. So, if you try using one of the hints, for example
> > >> openjpa.hint.OptimizeResultCount and your designated database
> > >> doesn't have
> > >> the capability to provide the necessary processing for this
> request,
> > >> then it
> > >> would be ignored.
> > >>
> > >> Otherwise, if you pass in a hint that OpenJPA knows nothing about
> > >> (let's
> > >> just say openjpa.hint.FailFast), then you would receive an
> > >> ArgumentException. The curious thing here is that this seems to
> > >> contradict
> > >> the hint processing as defined by JPA 2.0. I believe invalid
> hints
> > >> are
> > >> supposed to be ignored to allow for programming model
> compatibilities
> > >> between JPA providers. So, maybe there's some clean up necessary
> in
> > >> our
> > >> documentation.
> > >>
> > >> Does this help? We should probably open a JIRA to address this
> > >> documentation hiccup. If you don't have access to open a JIRA,
> then
> > >> let me
> > >> know and I can open one.
> > >>
> > >> Thanks,
> > >> Kevin
> > >>
> > >> On Wed, Dec 2, 2009 at 2:36 PM, KARR, DAVID (ATTCINW)
> > >> <dk068x@att.com>wrote:
> > >>
> > >>> I'm just reading through the docs (1.2.1) right now, and I
> noticed
> > >>> the
> > >>> following statement in section 10.1.7, "Query Hints":
> > >>>
> > >>> "Invalid hints or hints which can not be processed by a
> particular
> > >>> database are ignored. Otherwise, invalid hints will result in an
> > >>> ArgumentException being thrown."
> > >>>
> > >>> I'm a little confused by this. Under what circumstances will a
> > >>> hint be
> > >>> ignored, and when will it get an ArgumentException?
> > >>>
> > >
> > > Craig L Russell
> > > Architect, Sun Java Enterprise System http://db.apache.org/jdo
> > > 408 276-5638 mailto:Craig.Russell@sun.com
> > > P.S. A good JDO? O, Gasp!
> > >
> > >
> > >
> > >
> >
> >
> > -----
> > Pinaki
> > --
> > View this message in context:
> > http://n2.nabble.com/What-happens-with-invalid-query-hints-
> tp4102163p4107811.html
> > Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >
Yep, I think we're all in agreement on how we should process these hints.
But, the point of the original posting was that the documentation doesn't
explain this very well. So, we still need a JIRA to get this cleaned up.
Agree?
Kevin
On Thu, Dec 3, 2009 at 12:25 PM, Pinaki Poddar <ppoddar@apache.org> wrote:
>
> Craig is right.
>
> OpenJPA categories a hint key in the following categories (from JavaDoc on
> HintHandler)
> * 1. Supported: A key is known to this receiver as collected from
> different
> * parts of the system. The value of a supported key is recorded and
> * available via {@link #getHints()} method.
> * 2. Recognized: A key is not known to this receiver but has a prefix
> which
> * is known to this receiver. The value of a recognized key is not
> recorded
> * but its value is available via {@link
> FetchConfiguration#getHint(String)}
> * 3. Unrecognized: A key is neither supported nor recognized. The value
> of
> a
> * unrecognized key is neither recorded nor set anywhere.
>
> Semantically, this categorization aligns with Craig's classification as
> Craig's category 1 = Supported
> Craig's category 2 = Unrecognized
> Craig's category 3 = Recognized
>
> The runtime exception handling behavior is somewhat more lenient than what
> Craig describes. None of the three categories of hint key raises an
> exception. Recognized key is not recorded i.e. they do not appear in
> getHints() list. They only generate a warning message. The only exception
> scenario is a Supported key supplied with an incompatiable value.
>
>
>
> Craig L Russell wrote:
> >
> > The specification offers this explanation (3.8.9 in the draft
> > specification dated 2009-10-06):
> >
> > Vendors are permitted to support the use of additional, vendor-
> > specific locking hints. Vendor-specific
> > hints must not use the javax.persistence namespace. Vendor-specific
> > hints must be ignored if
> > they are not understood.
> >
> > So the model is that there are three categories of hints:
> >
> > 1. hints that are known to OpenJPA, which are hints defined by the
> > standard plus the hints that are defined by OpenJPA to extend the
> > standard hints. These hints are defined in the OpenJPA name space
> > "openjpa.hint.*" or in the standard hint name space
> > "javax.persistence.*"
> >
> > 2. hints that are defined by other vendors in their own name space.
> >
> > 3. hints that are in the OpenJPA name space but are not known to
> > OpenJPA. These are usually typos by the user. For example,
> > "openjpa.hint.OOptimizeResultCount".
> >
> > Category 1 hints are honored if possible (e.g. the database in use
> > supports the hint).
> >
> > Category 2 hints are ignored by OpenJPA. This allows you to use the
> > same set of hints in a program with different persistence vendors.
> >
> > Category 3 hints result in an exception. Typos should be caught and
> > reported.
> >
> > Sometimes we developers assume that users read and understand the
> > specification along with the OpenJPA user documentation. Bad assumption.
> >
> > By the way, this model for hints follows the general model for
> > properties in several JCP specifications.
> >
> > Craig
> >
> > On Dec 2, 2009, at 3:55 PM, Kevin Sutter wrote:
> >
> >> :-) Yeah, that's kind of confusing, isn't it? I'm assuming that it
> >> should
> >> read as follows:
> >>
> >> "Hints which can not be processed by a particular database are
> >> ignored.
> >> Otherwise, invalid hints will result in an ArgumentException being
> >> thrown."
> >>
> >> OpenJPA has defined certain hints (and JPA 2.0 has defined some some
> >> hints)
> >> that could be used with Queries. Some of these hints do not apply
> >> to all
> >> databases. So, if you try using one of the hints, for example
> >> openjpa.hint.OptimizeResultCount and your designated database
> >> doesn't have
> >> the capability to provide the necessary processing for this request,
> >> then it
> >> would be ignored.
> >>
> >> Otherwise, if you pass in a hint that OpenJPA knows nothing about
> >> (let's
> >> just say openjpa.hint.FailFast), then you would receive an
> >> ArgumentException. The curious thing here is that this seems to
> >> contradict
> >> the hint processing as defined by JPA 2.0. I believe invalid hints
> >> are
> >> supposed to be ignored to allow for programming model compatibilities
> >> between JPA providers. So, maybe there's some clean up necessary in
> >> our
> >> documentation.
> >>
> >> Does this help? We should probably open a JIRA to address this
> >> documentation hiccup. If you don't have access to open a JIRA, then
> >> let me
> >> know and I can open one.
> >>
> >> Thanks,
> >> Kevin
> >>
> >> On Wed, Dec 2, 2009 at 2:36 PM, KARR, DAVID (ATTCINW)
> >> <dk068x@att.com>wrote:
> >>
> >>> I'm just reading through the docs (1.2.1) right now, and I noticed
> >>> the
> >>> following statement in section 10.1.7, "Query Hints":
> >>>
> >>> "Invalid hints or hints which can not be processed by a particular
> >>> database are ignored. Otherwise, invalid hints will result in an
> >>> ArgumentException being thrown."
> >>>
> >>> I'm a little confused by this. Under what circumstances will a
> >>> hint be
> >>> ignored, and when will it get an ArgumentException?
> >>>
> >
> > Craig L Russell
> > Architect, Sun Java Enterprise System http://db.apache.org/jdo
> > 408 276-5638 mailto:Craig.Russell@sun.com
> > P.S. A good JDO? O, Gasp!
> >
> >
> >
> >
>
>
> -----
> Pinaki
> --
> View this message in context:
> http://n2.nabble.com/What-happens-with-invalid-query-hints-tp4102163p4107811.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
Craig is right.
OpenJPA categories a hint key in the following categories (from JavaDoc on
HintHandler)
* 1. Supported: A key is known to this receiver as collected from
different
* parts of the system. The value of a supported key is recorded and
* available via {@link #getHints()} method.
* 2. Recognized: A key is not known to this receiver but has a prefix
which
* is known to this receiver. The value of a recognized key is not
recorded
* but its value is available via {@link
FetchConfiguration#getHint(String)}
* 3. Unrecognized: A key is neither supported nor recognized. The value of
a
* unrecognized key is neither recorded nor set anywhere.
Semantically, this categorization aligns with Craig's classification as
Craig's category 1 = Supported
Craig's category 2 = Unrecognized
Craig's category 3 = Recognized
The runtime exception handling behavior is somewhat more lenient than what
Craig describes. None of the three categories of hint key raises an
exception. Recognized key is not recorded i.e. they do not appear in
getHints() list. They only generate a warning message. The only exception
scenario is a Supported key supplied with an incompatiable value.
Craig L Russell wrote:
>
> The specification offers this explanation (3.8.9 in the draft
> specification dated 2009-10-06):
>
> Vendors are permitted to support the use of additional, vendor-
> specific locking hints. Vendor-specific
> hints must not use the javax.persistence namespace. Vendor-specific
> hints must be ignored if
> they are not understood.
>
> So the model is that there are three categories of hints:
>
> 1. hints that are known to OpenJPA, which are hints defined by the
> standard plus the hints that are defined by OpenJPA to extend the
> standard hints. These hints are defined in the OpenJPA name space
> "openjpa.hint.*" or in the standard hint name space
> "javax.persistence.*"
>
> 2. hints that are defined by other vendors in their own name space.
>
> 3. hints that are in the OpenJPA name space but are not known to
> OpenJPA. These are usually typos by the user. For example,
> "openjpa.hint.OOptimizeResultCount".
>
> Category 1 hints are honored if possible (e.g. the database in use
> supports the hint).
>
> Category 2 hints are ignored by OpenJPA. This allows you to use the
> same set of hints in a program with different persistence vendors.
>
> Category 3 hints result in an exception. Typos should be caught and
> reported.
>
> Sometimes we developers assume that users read and understand the
> specification along with the OpenJPA user documentation. Bad assumption.
>
> By the way, this model for hints follows the general model for
> properties in several JCP specifications.
>
> Craig
>
> On Dec 2, 2009, at 3:55 PM, Kevin Sutter wrote:
>
>> :-) Yeah, that's kind of confusing, isn't it? I'm assuming that it
>> should
>> read as follows:
>>
>> "Hints which can not be processed by a particular database are
>> ignored.
>> Otherwise, invalid hints will result in an ArgumentException being
>> thrown."
>>
>> OpenJPA has defined certain hints (and JPA 2.0 has defined some some
>> hints)
>> that could be used with Queries. Some of these hints do not apply
>> to all
>> databases. So, if you try using one of the hints, for example
>> openjpa.hint.OptimizeResultCount and your designated database
>> doesn't have
>> the capability to provide the necessary processing for this request,
>> then it
>> would be ignored.
>>
>> Otherwise, if you pass in a hint that OpenJPA knows nothing about
>> (let's
>> just say openjpa.hint.FailFast), then you would receive an
>> ArgumentException. The curious thing here is that this seems to
>> contradict
>> the hint processing as defined by JPA 2.0. I believe invalid hints
>> are
>> supposed to be ignored to allow for programming model compatibilities
>> between JPA providers. So, maybe there's some clean up necessary in
>> our
>> documentation.
>>
>> Does this help? We should probably open a JIRA to address this
>> documentation hiccup. If you don't have access to open a JIRA, then
>> let me
>> know and I can open one.
>>
>> Thanks,
>> Kevin
>>
>> On Wed, Dec 2, 2009 at 2:36 PM, KARR, DAVID (ATTCINW)
>> <dk068x@att.com>wrote:
>>
>>> I'm just reading through the docs (1.2.1) right now, and I noticed
>>> the
>>> following statement in section 10.1.7, "Query Hints":
>>>
>>> "Invalid hints or hints which can not be processed by a particular
>>> database are ignored. Otherwise, invalid hints will result in an
>>> ArgumentException being thrown."
>>>
>>> I'm a little confused by this. Under what circumstances will a
>>> hint be
>>> ignored, and when will it get an ArgumentException?
>>>
>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>
>
-----
Pinaki
--
View this message in context: http://n2.nabble.com/What-happens-with-invalid-query-hints-tp4102163p4107811.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
When you call cc.merge(ooo); any changes made to that instance while it was
detached will be persisted to the DB.
I assume your comment "Here I modify the ooo but I want this modif to be
persist, not the other one before" means that you only want the changes from
after the tran begins to be persistent... If that assumption is correct,
you'll need to get a new instance of ooo to make the changes on.
--
Thanks,
Rick
On Thu, Dec 3, 2009 at 8:49 AM, Jean-Baptiste BRIAUD -- Novlog <
j-b.briaud@novlog.com> wrote:
> Hi the list,
>
> Am i right on the following pseudo code ?
>
> // Note the detach.
> // getFullById come back with an instance of MyObject from the
> primary key
> final MyObject ooo = detach(getFullById(cc....
>
> < Here I modify (a lot) ooo but don't wan't the modif to be
> persist>
>
> try {
> cc.beginTransaction();
>
> <Here I modify the ooo but I want this modif to be
> persist, not the other one before>
>
> cc.merge(ooo);
> cc.commitTransaction();
>
> } catch (...) {
> cc.rollbackTransaction();
> }
>
> Thanks !
Hi the list,
Am i right on the following pseudo code ?
// Note the detach.
// getFullById come back with an instance of MyObject from the primary key
final MyObject ooo = detach(getFullById(cc....
< Here I modify (a lot) ooo but don't wan't the modif to be persist>
try {
cc.beginTransaction();
<Here I modify the ooo but I want this modif to be persist, not the
other one before>
cc.merge(ooo);
cc.commitTransaction();
} catch (...) {
cc.rollbackTransaction();
}
Thanks !
Marc -
In the case where you call em.find(...) and it takes 500ms how long does
that operation take if the result doesn't need to be detached? The reason I
ask is that I've been doing some performance work and we found that in some
instances we are spending way too much time detaching Entities.
--
Thanks,
Rick
On Thu, Dec 3, 2009 at 6:06 AM, Marc Logemann <li@logemann.org> wrote:
> Hi,
>
> i am facing some weird performance issues. Given this JPA Query:
>
> public class SomeDao {
> @SuppressWarnings("unchecked")
> public Object getMetaData(Foo.class, long oid) {
> Object o = em.find(clazz, client);
> return o;
> }
> ..
> }
>
>
> @Entity
> @VersionColumn(name = "jpaversion")
> @Table(name = "foo")
> public class Foo extends BasicClientMetaData {
>
> @Id
> @Column(name = "client_oid")
> private long client;
> ...
> }
>
> @MappedSuperclass
> public class BasicClientMetaData implements MinMaxWeightAware {
>
>
> @Column(name = "custnr")
> private String customerNumber;
>
> @Column(name = "maxweight")
> private float maxWeightStandard;
> ..
> }
>
> When i call the getMetaData() of SomeDao.class (which is transactional and
> gets detached when its returned to the caller), i measured 500ms for this
> operation. The underlying SQL only consumes 20ms which i checked by setting
> the SQL log level to TRACE.
>
> Why is there such a difference? I mean, detaching cant be such an issue
> from performance perspective. I only have this issue with exactly these kind
> of classes (children of BasicClientMetaData).
>
> But i also have other classes which have the @MappedSuperclass which work
> without performance problems. Does anyone have a hint where i can look out
> for?
>
>
> thanks.
>
> ---
> regards
> Marc Logemann
> http://www.logemann.org
> http://www.logentis.de
>
>
>
>
>
I'm not on the Mojo list, so I'm not sure what they're saying there, but I do know from their JIRA that there are only 2 issues in the way of a release and one of them is relatively trivial http://jira.codehaus.org/browse/MOPENJPA-3 You could vote for it I guess. The other issue is something I know nothing about. I downloaded the source from svn and it compiles easily with maven and you can install the snapshot to your local repo: svn checkout https://svn.codehaus.org/mojo/trunk/mojo/openjpa-maven-plugin openjpa-maven-plugin Michael Vorburger on 03/12/09 10:45, wrote: > Hello Mojoers, I support the request for an e.g. non-SNAPSHOT v1.1 > OpenJPA Maven plugin published to a repo somewhere... > > Would be nice to be able to use the > http://jira.codehaus.org/browse/MOPENJPA-8 fix! > > > -----Original Message----- > From: Adam Hardy [mailto:adam.sql@cyberspaceroad.com] > Sent: Wednesday, December 02, 2009 7:04 PM > To: users@openjpa.apache.org > Subject: Re: openjpa-maven-plugin snapshot > > Oh I thought the dev guys for the plugin preferred this user list. > > No problem. It looks like I'll have to download the source and have a go > at it myself anyway. > > > Regards > Adam > > Michael Dick on 02/12/09 16:14, wrote: >> Hi all, >> >> The maven plugin is something different. The code is in codehaus SVN > and the >> resulting binaries are probably published to a codehaus m2-snapshot >> repository. >> >> I don't know how often those get published, so I've cross-posted to > their >> users email list. >> >> Sorry for the confusion, >> >> -mike >> >> On Tue, Dec 1, 2009 at 5:13 PM, Adam Hardy > <adam.sql@cyberspaceroad.com>wrote: >>> ljnelson on 01/12/09 20:47, wrote: >>> >>>> On Tue, Dec 1, 2009 at 1:48 PM, Michael Dick [via OpenJPA] < >>>> > ml-node+4095467-513228112@n2.nabble.com<ml-node%2B4095467-513228112@n2.n > abble.com> > <ml-node%2B4095467-513228112@n2.nabble.com<ml-node%252B4095467-513228112 > @n2.nabble.com> >>>>> wrote: >>>>> >>>> I publish the snapshots to the m2-snapshot repository on >>>>> people.apache.orgfairly regularly. You can find 1.1.1-SNAPSHOT at >>>>> >>>>> >>>>> > http://people.apache.org/repo/m2-snapshot-repository/org/apache/openjpa/ > openjpa/1.1.1-SNAPSHOT/ >>>>> >>>> (Not part of this conversation, but is that for the OpenJPA Maven > plugin, >>>> or >>>> just OpenJPA?) >>>> >>> Looks like OpenJPA itself. I should have mentioned the > openjpa-maven-plugin >>> in the text as well as the title. >>> >>> Interesting to know about the repository for Apache snapshots though. >>> >>> Regards >>> Adam >>> > > > ____________________________________________________________ > > • This email and any files transmitted with it are CONFIDENTIAL and intended > solely for the use of the individual or entity to which they are addressed. > • Any unauthorized copying, disclosure, or distribution of the material within > this email is strictly forbidden. > • Any views or opinions presented within this e-mail are solely those of the > author and do not necessarily represent those of Odyssey Financial > Technologies SA unless otherwise specifically stated. > • An electronic message is not binding on its sender. Any message referring to > a binding engagement must be confirmed in writing and duly signed. > • If you have received this email in error, please notify the sender immediately > and delete the original. >
small correction :
public class SomeDao {
@SuppressWarnings("unchecked")
public Object getMetaData(Class clazz, long oid) {
Object o = em.find(clazz, oid);
return o;
}
..
}
CALLER:
Object o = someDao.getMetaData(Foo.class, 1);
---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de
Am 03.12.2009 um 13:06 schrieb Marc Logemann:
> Hi,
>
> i am facing some weird performance issues. Given this JPA Query:
>
> public class SomeDao {
> @SuppressWarnings("unchecked")
> public Object getMetaData(Foo.class, long oid) {
> Object o = em.find(clazz, client);
> return o;
> }
> ..
> }
>
>
> @Entity
> @VersionColumn(name = "jpaversion")
> @Table(name = "foo")
> public class Foo extends BasicClientMetaData {
>
> @Id
> @Column(name = "client_oid")
> private long client;
> ...
> }
>
> @MappedSuperclass
> public class BasicClientMetaData implements MinMaxWeightAware {
>
>
> @Column(name = "custnr")
> private String customerNumber;
>
> @Column(name = "maxweight")
> private float maxWeightStandard;
> ..
> }
>
> When i call the getMetaData() of SomeDao.class (which is transactional and gets detached
when its returned to the caller), i measured 500ms for this operation. The underlying SQL
only consumes 20ms which i checked by setting the SQL log level to TRACE.
>
> Why is there such a difference? I mean, detaching cant be such an issue from performance
perspective. I only have this issue with exactly these kind of classes (children of BasicClientMetaData).
>
> But i also have other classes which have the @MappedSuperclass which work without performance
problems. Does anyone have a hint where i can look out for?
>
>
> thanks.
>
> ---
> regards
> Marc Logemann
> http://www.logemann.org
> http://www.logentis.de
>
>
>
>
Hi,
i am facing some weird performance issues. Given this JPA Query:
public class SomeDao {
@SuppressWarnings("unchecked")
public Object getMetaData(Foo.class, long oid) {
Object o = em.find(clazz, client);
return o;
}
..
}
@Entity
@VersionColumn(name = "jpaversion")
@Table(name = "foo")
public class Foo extends BasicClientMetaData {
@Id
@Column(name = "client_oid")
private long client;
...
}
@MappedSuperclass
public class BasicClientMetaData implements MinMaxWeightAware {
@Column(name = "custnr")
private String customerNumber;
@Column(name = "maxweight")
private float maxWeightStandard;
..
}
When i call the getMetaData() of SomeDao.class (which is transactional and gets detached when
its returned to the caller), i measured 500ms for this operation. The underlying SQL only
consumes 20ms which i checked by setting the SQL log level to TRACE.
Why is there such a difference? I mean, detaching cant be such an issue from performance perspective.
I only have this issue with exactly these kind of classes (children of BasicClientMetaData).
But i also have other classes which have the @MappedSuperclass which work without performance
problems. Does anyone have a hint where i can look out for?
thanks.
---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de
Hello Mojoers, I support the request for an e.g. non-SNAPSHOT v1.1 OpenJPA Maven plugin published to a repo somewhere... Would be nice to be able to use the http://jira.codehaus.org/browse/MOPENJPA-8 fix! -----Original Message----- From: Adam Hardy [mailto:adam.sql@cyberspaceroad.com] Sent: Wednesday, December 02, 2009 7:04 PM To: users@openjpa.apache.org Subject: Re: openjpa-maven-plugin snapshot Oh I thought the dev guys for the plugin preferred this user list. No problem. It looks like I'll have to download the source and have a go at it myself anyway. Regards Adam Michael Dick on 02/12/09 16:14, wrote: > Hi all, > > The maven plugin is something different. The code is in codehaus SVN and the > resulting binaries are probably published to a codehaus m2-snapshot > repository. > > I don't know how often those get published, so I've cross-posted to their > users email list. > > Sorry for the confusion, > > -mike > > On Tue, Dec 1, 2009 at 5:13 PM, Adam Hardy <adam.sql@cyberspaceroad.com>wrote: > >> ljnelson on 01/12/09 20:47, wrote: >> >>> On Tue, Dec 1, 2009 at 1:48 PM, Michael Dick [via OpenJPA] < >>> ml-node+4095467-513228112@n2.nabble.com<ml-node%2B4095467-513228112@n2.n abble.com> >>> <ml-node%2B4095467-513228112@n2.nabble.com<ml-node%252B4095467-513228112 @n2.nabble.com> >>>> wrote: >>>> >>> I publish the snapshots to the m2-snapshot repository on >>>> people.apache.orgfairly regularly. You can find 1.1.1-SNAPSHOT at >>>> >>>> >>>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/openjpa/ openjpa/1.1.1-SNAPSHOT/ >>>> >>>> >>> (Not part of this conversation, but is that for the OpenJPA Maven plugin, >>> or >>> just OpenJPA?) >>> >> Looks like OpenJPA itself. I should have mentioned the openjpa-maven-plugin >> in the text as well as the title. >> >> Interesting to know about the repository for Apache snapshots though. >> >> Regards >> Adam >> > ____________________________________________________________ • This email and any files transmitted with it are CONFIDENTIAL and intended solely for the use of the individual or entity to which they are addressed. • Any unauthorized copying, disclosure, or distribution of the material within this email is strictly forbidden. • Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of Odyssey Financial Technologies SA unless otherwise specifically stated. • An electronic message is not binding on its sender. Any message referring to a binding engagement must be confirmed in writing and duly signed. • If you have received this email in error, please notify the sender immediately and delete the original.
The specification offers this explanation (3.8.9 in the draft specification dated 2009-10-06): Vendors are permitted to support the use of additional, vendor- specific locking hints. Vendor-specific hints must not use the javax.persistence namespace. Vendor-specific hints must be ignored if they are not understood. So the model is that there are three categories of hints: 1. hints that are known to OpenJPA, which are hints defined by the standard plus the hints that are defined by OpenJPA to extend the standard hints. These hints are defined in the OpenJPA name space "openjpa.hint.*" or in the standard hint name space "javax.persistence.*" 2. hints that are defined by other vendors in their own name space. 3. hints that are in the OpenJPA name space but are not known to OpenJPA. These are usually typos by the user. For example, "openjpa.hint.OOptimizeResultCount". Category 1 hints are honored if possible (e.g. the database in use supports the hint). Category 2 hints are ignored by OpenJPA. This allows you to use the same set of hints in a program with different persistence vendors. Category 3 hints result in an exception. Typos should be caught and reported. Sometimes we developers assume that users read and understand the specification along with the OpenJPA user documentation. Bad assumption. By the way, this model for hints follows the general model for properties in several JCP specifications. Craig On Dec 2, 2009, at 3:55 PM, Kevin Sutter wrote: > :-) Yeah, that's kind of confusing, isn't it? I'm assuming that it > should > read as follows: > > "Hints which can not be processed by a particular database are > ignored. > Otherwise, invalid hints will result in an ArgumentException being > thrown." > > OpenJPA has defined certain hints (and JPA 2.0 has defined some some > hints) > that could be used with Queries. Some of these hints do not apply > to all > databases. So, if you try using one of the hints, for example > openjpa.hint.OptimizeResultCount and your designated database > doesn't have > the capability to provide the necessary processing for this request, > then it > would be ignored. > > Otherwise, if you pass in a hint that OpenJPA knows nothing about > (let's > just say openjpa.hint.FailFast), then you would receive an > ArgumentException. The curious thing here is that this seems to > contradict > the hint processing as defined by JPA 2.0. I believe invalid hints > are > supposed to be ignored to allow for programming model compatibilities > between JPA providers. So, maybe there's some clean up necessary in > our > documentation. > > Does this help? We should probably open a JIRA to address this > documentation hiccup. If you don't have access to open a JIRA, then > let me > know and I can open one. > > Thanks, > Kevin > > On Wed, Dec 2, 2009 at 2:36 PM, KARR, DAVID (ATTCINW) > <dk068x@att.com>wrote: > >> I'm just reading through the docs (1.2.1) right now, and I noticed >> the >> following statement in section 10.1.7, "Query Hints": >> >> "Invalid hints or hints which can not be processed by a particular >> database are ignored. Otherwise, invalid hints will result in an >> ArgumentException being thrown." >> >> I'm a little confused by this. Under what circumstances will a >> hint be >> ignored, and when will it get an ArgumentException? >> Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:Craig.Russell@sun.com P.S. A good JDO? O, Gasp!
> -----Original Message----- > From: Kevin Sutter [mailto:kwsutter@gmail.com] > Sent: Wednesday, December 02, 2009 3:56 PM > To: users@openjpa.apache.org > Subject: Re: What happens with invalid query hints? > [deleted] > > Otherwise, if you pass in a hint that OpenJPA knows nothing about > (let's > just say openjpa.hint.FailFast), then you would receive an > ArgumentException. The curious thing here is that this seems to > contradict > the hint processing as defined by JPA 2.0. I believe invalid hints are > supposed to be ignored to allow for programming model compatibilities > between JPA providers. So, maybe there's some clean up necessary in > our > documentation. > > Does this help? We should probably open a JIRA to address this > documentation hiccup. If you don't have access to open a JIRA, then > let me > know and I can open one. I may or may not have an account as of yet, but as I'm going to be spending a lot of time with this in the next few months (at least), I think it's worthwhile for me to create it. I'll have it reference your statements here. > On Wed, Dec 2, 2009 at 2:36 PM, KARR, DAVID (ATTCINW) > <dk068x@att.com>wrote: > > > I'm just reading through the docs (1.2.1) right now, and I noticed > the > > following statement in section 10.1.7, "Query Hints": > > > > "Invalid hints or hints which can not be processed by a particular > > database are ignored. Otherwise, invalid hints will result in an > > ArgumentException being thrown." > > > > I'm a little confused by this. Under what circumstances will a hint > be > > ignored, and when will it get an ArgumentException? > >
Hi shihoir, Yeah, the openjpa.Optimistic property is not well documented. The only reference is to the property and the valid values of true and false [1]. With the updates being done to formalize the Pessimistic lock manager in JPA 2.0, we should probably clean up the documentation here as well. Another source of information for OpenJPA's locking capabilities is the WebSphere InfoCenter [2]. This is specific to the OpenJPA 1.2.x branch, but it does give more background on the various locking mechanisms available. I'm going to copy Albert on this reply since he was instrumental in the JPA 2.0 implementation for the pessimistic lock manager. He might have more insights on the documentation for these locking mechanisms. Thanks, Kevin [1] http://openjpa.apache.org/builds/latest/docs/manual/manual.html#openjpa.Optimistic [2] http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tejb_jpadeadlock.html On Mon, Nov 30, 2009 at 8:06 AM, shihoir <shihoir@gmail.com> wrote: > Hi, all. > What is an option "openjpa.Optimistic" for? > In Lock Object Locking Guide, there is no guide for that option. > > http://openjpa.apache.org/builds/2.0.0-M3/apache-openjpa-2.0.0-M3/docs/manual/ref_guide_locking.html > I want to know feature of "openjpa.Optimistic" with "openjpa.LockManager" > option. > > thanks. > //julia chang >
This sounds very strange. From your description, I have no idea why Date and Boolean attributes are having problems with Oracle. And, why a Union All is being generated for a simple find operation baffles me as well. Unless there is some inheritance or eagerly fetched relationships involved. Still, I thought OpenJPA used Joins over Unions. Can you simplify the problem to a simple testcase that could be provided? Thanks, Kevin On Tue, Dec 1, 2009 at 7:15 AM, himadri <hima_das@yahoo.co.in> wrote: > > Hi, > > I have an EJB3.0 application deployed on Weblogic 10.3 and Oracle 10g DB. I > have an entity Typed which has Date and Boolean datatypes. em.persist is > sucessful. > > But whereever there is em.find() on any entity in this application , I have > observed that open JPA tries to get Union of all entities. This may be > because its first time , But it fails with exception > > "[BEA][Oracle JDBC Driver][Oracle]ORA-01790:expression must have same > datatype as corresponding expression" > > The SQL generated is union all of all entities in the application . For > boolean FLAG_F , MOMENT_F wrong sql is generated. It should have to_date > function for date. I have used DATE and boolean in Entity class. > > SELECT 0, t0.ID, t0.version, t0.NAME_F, '', 0, NULL, '', 0, 0, > '1970-01-01', > '', 0.0 FROM AddOn_T t0 WHERE t0.ID = ? > UNION ALL > SELECT 1, t0.ID, t0.version, '', '', t0.COUNTER_F, t0.DATA_F, t0.ENUMED1_F, > t0.ENUMED2_F, t0.FLAG_F, t0.MOMENT_F, t0.NAME_F, t0.VALUE_F FROM TYPED_T t0 > WHERE t0.ID = ? [params=(String) 30, (String) 30]} [code=1790, state=HY000] > > I guess openJPA fails to add to_date function for DATE and surrounding > chars > for boolean. Is this a bug or some settings available. Why is it trying to > get union all even for em.find(... ) ? > > Thanks in advance.. > - H > > > > > > > -- > View this message in context: > http://n2.nabble.com/Open-JPA-generates-incorrect-Union-All-for-Date-and-Boolean-Datatype-tp4093559p4093559.html > Sent from the OpenJPA Users mailing list archive at Nabble.com. >
:-) Yeah, that's kind of confusing, isn't it? I'm assuming that it should read as follows: "Hints which can not be processed by a particular database are ignored. Otherwise, invalid hints will result in an ArgumentException being thrown." OpenJPA has defined certain hints (and JPA 2.0 has defined some some hints) that could be used with Queries. Some of these hints do not apply to all databases. So, if you try using one of the hints, for example openjpa.hint.OptimizeResultCount and your designated database doesn't have the capability to provide the necessary processing for this request, then it would be ignored. Otherwise, if you pass in a hint that OpenJPA knows nothing about (let's just say openjpa.hint.FailFast), then you would receive an ArgumentException. The curious thing here is that this seems to contradict the hint processing as defined by JPA 2.0. I believe invalid hints are supposed to be ignored to allow for programming model compatibilities between JPA providers. So, maybe there's some clean up necessary in our documentation. Does this help? We should probably open a JIRA to address this documentation hiccup. If you don't have access to open a JIRA, then let me know and I can open one. Thanks, Kevin On Wed, Dec 2, 2009 at 2:36 PM, KARR, DAVID (ATTCINW) <dk068x@att.com>wrote: > I'm just reading through the docs (1.2.1) right now, and I noticed the > following statement in section 10.1.7, "Query Hints": > > "Invalid hints or hints which can not be processed by a particular > database are ignored. Otherwise, invalid hints will result in an > ArgumentException being thrown." > > I'm a little confused by this. Under what circumstances will a hint be > ignored, and when will it get an ArgumentException? >
I'm just reading through the docs (1.2.1) right now, and I noticed the following statement in section 10.1.7, "Query Hints": "Invalid hints or hints which can not be processed by a particular database are ignored. Otherwise, invalid hints will result in an ArgumentException being thrown." I'm a little confused by this. Under what circumstances will a hint be ignored, and when will it get an ArgumentException?
Both a source and javadoc jar are in the maven repos at - http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-jpa_3.0_spec/1.0/ And the source can be checked out from the Apache svn repo at - https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jpa_3.0_spec-1.0/ -Donald Andrew Thompson wrote: > http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-jpa_3.0_spec/ is generally a good location for jars with sources for opensource projects. > > > > On Sun, 2009-11-29 at 13:27 -0500, Jaguar Finch wrote: >> Hello all, >> >> I'm new to OpenJPA. Where can I find source or javadocs for the >> geronimo-jpa >> jar included with OpenJPA 1.2.1 ? >> >> Thank you! >> >> > >
Jeremy, Good to know I'm not going bat crap crazy. I've spent a decent amount of time trying to figure out the class loading problem. I'm currently using Tomcat 6x. Seth Jeremy Bauer wrote: > > Seth, > > Thanks for reporting this problem. I've opened JIRA OPENJPA-1410[1]. The > code in PersistenceProviderImpl that sets up validation looks like it > might > be suspect to classloading issues. Which version of Tomcat are you using? > > -Jeremy > > [1] https://issues.apache.org/jira/browse/OPENJPA-1410 > > On Tue, Dec 1, 2009 at 5:56 AM, seth.jackson > <seth.jackson.ctr@dfas.mil>wrote: > >> >> After further review, using Glassfish 2.1.1 I received this error message >> in >> the server log: >> >> Caused by: java.lang.LinkageError: loader constraint violation: when >> resolving method >> >> "org.apache.openjpa.persistence.validation.ValidationUtils.setupValidation(Lorg/apache/openjpa/conf/OpenJPAConfiguration;)Z" >> the class loader (instance of >> org/apache/catalina/loader/WebappClassLoader) >> of the current class, >> org/apache/openjpa/persistence/PersistenceProviderImpl, and the class >> loader >> (instance of sun/misc/Launcher$AppClassLoader) for resolved class, >> org/apache/openjpa/persistence/validation/ValidationUtils, have different >> Class objects for the type org/apache/openjpa/conf/OpenJPAConfiguration >> used >> in the signature >> >> So it appears to be the WebappClassLoader and the AppClassLoader are both >> loading the OpenJPAConfiguration from the same JAR file, causing the >> error >> when the class is trying to be resolved in this particular method.. >> >> >> >> seth.jackson wrote: >> > >> > It appears something was modified in OpenJPA 2.0 M3 from M2 that causes >> a >> > LinkageError. >> > >> > In my current environment, I've tested both Glassfish and Tomcat using >> M2 >> > and M3. M2 runs without problems, but M3 throws a linkage error as >> > follows: >> > >> > Caused by: java.lang.LinkageError: loader constraint violation: loader >> > (instance of sun/misc/Launcher$AppClassLoader) previously initiated >> > loading for a different type with name >> > "org/apache/openjpa/conf/OpenJPAConfiguration" >> > at java.lang.ClassLoader.defineClass1(Native Method) >> > at java.lang.ClassLoader.defineClass(ClassLoader.java:621) >> > at >> > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) >> > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) >> > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) >> > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) >> > at java.security.AccessController.doPrivileged(Native Method) >> > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) >> > at java.lang.ClassLoader.loadClass(ClassLoader.java:307) >> > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) >> > at java.lang.ClassLoader.loadClass(ClassLoader.java:252) >> > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) >> > at >> > >> org.apache.openjpa.persistence.validation.ValidationUtils.setupValidation(ValidationUtils.java:53) >> > at >> > >> org.apache.openjpa.persistence.PersistenceProviderImpl.loadValidator(PersistenceProviderImpl.java:290) >> > at >> > >> org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:97) >> > at >> > >> org.apache.openjpa.persistence.OpenJPAPersistence.createEntityManagerFactory(OpenJPAPersistence.java:128) >> > at >> > >> org.apache.openjpa.persistence.OpenJPAPersistence.createEntityManagerFactory(OpenJPAPersistence.java:111) >> > at test_test.user.UserAction.execute(UserAction.java:39) >> > >> > >> > I've already confirmed that the OpenJPA classes in question do NOT >> exist >> > in any other JARs in the path. >> > >> > ValidationUtils.setupValidation(ValidationUtils.java:53) calls the >> > OpenJPAConfiguration.getConfigurationLog(). The object being referenced >> is >> > JDBCConfigurationImpl, which in other classes retrieves the log >> reference >> > perfectly fine, before it gets to the offending line. >> > >> >> -- >> View this message in context: >> http://n2.nabble.com/Struts-2x-OpenJPA-2-0-M3-Tomcat-or-Glassfish-tp4087312p4093228.html >> Sent from the OpenJPA Users mailing list archive at Nabble.com. >> > > -- View this message in context: http://n2.nabble.com/Struts-2x-OpenJPA-2-0-M3-Tomcat-or-Glassfish-tp4087312p4101439.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Seth, Thanks for reporting this problem. I've opened JIRA OPENJPA-1410[1]. The code in PersistenceProviderImpl that sets up validation looks like it might be suspect to classloading issues. Which version of Tomcat are you using? -Jeremy [1] https://issues.apache.org/jira/browse/OPENJPA-1410 On Tue, Dec 1, 2009 at 5:56 AM, seth.jackson <seth.jackson.ctr@dfas.mil>wrote: > > After further review, using Glassfish 2.1.1 I received this error message > in > the server log: > > Caused by: java.lang.LinkageError: loader constraint violation: when > resolving method > > "org.apache.openjpa.persistence.validation.ValidationUtils.setupValidation(Lorg/apache/openjpa/conf/OpenJPAConfiguration;)Z" > the class loader (instance of org/apache/catalina/loader/WebappClassLoader) > of the current class, > org/apache/openjpa/persistence/PersistenceProviderImpl, and the class > loader > (instance of sun/misc/Launcher$AppClassLoader) for resolved class, > org/apache/openjpa/persistence/validation/ValidationUtils, have different > Class objects for the type org/apache/openjpa/conf/OpenJPAConfiguration > used > in the signature > > So it appears to be the WebappClassLoader and the AppClassLoader are both > loading the OpenJPAConfiguration from the same JAR file, causing the error > when the class is trying to be resolved in this particular method.. > > > > seth.jackson wrote: > > > > It appears something was modified in OpenJPA 2.0 M3 from M2 that causes a > > LinkageError. > > > > In my current environment, I've tested both Glassfish and Tomcat using M2 > > and M3. M2 runs without problems, but M3 throws a linkage error as > > follows: > > > > Caused by: java.lang.LinkageError: loader constraint violation: loader > > (instance of sun/misc/Launcher$AppClassLoader) previously initiated > > loading for a different type with name > > "org/apache/openjpa/conf/OpenJPAConfiguration" > > at java.lang.ClassLoader.defineClass1(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:621) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:307) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:252) > > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) > > at > > > org.apache.openjpa.persistence.validation.ValidationUtils.setupValidation(ValidationUtils.java:53) > > at > > > org.apache.openjpa.persistence.PersistenceProviderImpl.loadValidator(PersistenceProviderImpl.java:290) > > at > > > org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:97) > > at > > > org.apache.openjpa.persistence.OpenJPAPersistence.createEntityManagerFactory(OpenJPAPersistence.java:128) > > at > > > org.apache.openjpa.persistence.OpenJPAPersistence.createEntityManagerFactory(OpenJPAPersistence.java:111) > > at test_test.user.UserAction.execute(UserAction.java:39) > > > > > > I've already confirmed that the OpenJPA classes in question do NOT exist > > in any other JARs in the path. > > > > ValidationUtils.setupValidation(ValidationUtils.java:53) calls the > > OpenJPAConfiguration.getConfigurationLog(). The object being referenced > is > > JDBCConfigurationImpl, which in other classes retrieves the log reference > > perfectly fine, before it gets to the offending line. > > > > -- > View this message in context: > http://n2.nabble.com/Struts-2x-OpenJPA-2-0-M3-Tomcat-or-Glassfish-tp4087312p4093228.html > Sent from the OpenJPA Users mailing list archive at Nabble.com. >
Oh I thought the dev guys for the plugin preferred this user list. No problem. It looks like I'll have to download the source and have a go at it myself anyway. Regards Adam Michael Dick on 02/12/09 16:14, wrote: > Hi all, > > The maven plugin is something different. The code is in codehaus SVN and the > resulting binaries are probably published to a codehaus m2-snapshot > repository. > > I don't know how often those get published, so I've cross-posted to their > users email list. > > Sorry for the confusion, > > -mike > > On Tue, Dec 1, 2009 at 5:13 PM, Adam Hardy <adam.sql@cyberspaceroad.com>wrote: > >> ljnelson on 01/12/09 20:47, wrote: >> >>> On Tue, Dec 1, 2009 at 1:48 PM, Michael Dick [via OpenJPA] < >>> ml-node+4095467-513228112@n2.nabble.com<ml-node%2B4095467-513228112@n2.nabble.com> >>> <ml-node%2B4095467-513228112@n2.nabble.com<ml-node%252B4095467-513228112@n2.nabble.com> >>>> wrote: >>>> >>> I publish the snapshots to the m2-snapshot repository on >>>> people.apache.orgfairly regularly. You can find 1.1.1-SNAPSHOT at >>>> >>>> >>>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/openjpa/openjpa/1.1.1-SNAPSHOT/ >>>> >>>> >>> (Not part of this conversation, but is that for the OpenJPA Maven plugin, >>> or >>> just OpenJPA?) >>> >> Looks like OpenJPA itself. I should have mentioned the openjpa-maven-plugin >> in the text as well as the title. >> >> Interesting to know about the repository for Apache snapshots though. >> >> Regards >> Adam >> >
Hi all, The maven plugin is something different. The code is in codehaus SVN and the resulting binaries are probably published to a codehaus m2-snapshot repository. I don't know how often those get published, so I've cross-posted to their users email list. Sorry for the confusion, -mike On Tue, Dec 1, 2009 at 5:13 PM, Adam Hardy <adam.sql@cyberspaceroad.com>wrote: > ljnelson on 01/12/09 20:47, wrote: > >> On Tue, Dec 1, 2009 at 1:48 PM, Michael Dick [via OpenJPA] < >> ml-node+4095467-513228112@n2.nabble.com<ml-node%2B4095467-513228112@n2.nabble.com> >> <ml-node%2B4095467-513228112@n2.nabble.com<ml-node%252B4095467-513228112@n2.nabble.com> >> > >> >>> wrote: >>> >> >> I publish the snapshots to the m2-snapshot repository on >>> people.apache.orgfairly regularly. You can find 1.1.1-SNAPSHOT at >>> >>> >>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/openjpa/openjpa/1.1.1-SNAPSHOT/ >>> >>> >> (Not part of this conversation, but is that for the OpenJPA Maven plugin, >> or >> just OpenJPA?) >> > > Looks like OpenJPA itself. I should have mentioned the openjpa-maven-plugin > in the text as well as the title. > > Interesting to know about the repository for Apache snapshots though. > > Regards > Adam >