[org.apache.openjpa.persistence.ArgumentException - An error occurred while parsing the query filter select x from Person x. Error message: The name Person is not a recognized entity or identifi
Hi, I'm getting the following error trying to poll a JPA entity Person. There's no error in the code. Everything compiles ok with a mvn clean install and the Person entity does exist in the net.lr.tutorial.karaf.camel.jpa2jms.model package. I have installed all the necessary features I believe and I know it's correctly connection to the database because it's creating a sequence database for the primary key. 2014-01-30 21:33:59,848 | WARN | jms.model.Person | JpaConsumer | 125 - org.apache.camel.camel-core - 2.12.0 | Consumer Consumer[jpa://net.lr.tutorial.karaf.camel.jpa2jms.model.Person?consumer.delay=3500] failed polling endpoint: Endpoint[jpa://net.lr.tutorial.karaf.camel.jpa2jms.model.Person?consumer.delay=3500]. Will try again at next poll. Caused by: [org.apache.openjpa.persistence.ArgumentException - An error occurred while parsing the query filter select x from Person x. Error message: The name Person is not a recognized entity or identifier. Perhaps you meant Person, which is a close match. Known entity names: [Person]] openjpa-2.1.1-r422266:1148538 nonfatal user error org.apache.openjpa.persistence.ArgumentException: An error occurred while parsing the query filter select x from Person x. Error message: The name Person is not a recognized entity or identifier. Perhaps you meant Person, which is a close match. Known entity names: [Person] Any ideas? Sean -- View this message in context: http://openjpa.208410.n2.nabble.com/org-apache-openjpa-persistence-ArgumentException-An-error-occurred-while-parsing-the-query-filter-se-tp7585976.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: [org.apache.openjpa.persistence.ArgumentException - An error occurred while parsing the query filter select x from Person x. Error message: The name Person is not a recognized entity or identi
Please post the contents of your persistence.xml. Thanks, Rick On Wed, Feb 12, 2014 at 10:45 AM, Sebarry seanjamesba...@yahoo.co.ukwrote: Hi, I'm getting the following error trying to poll a JPA entity Person. There's no error in the code. Everything compiles ok with a mvn clean install and the Person entity does exist in the net.lr.tutorial.karaf.camel.jpa2jms.model package. I have installed all the necessary features I believe and I know it's correctly connection to the database because it's creating a sequence database for the primary key. 2014-01-30 21:33:59,848 | WARN | jms.model.Person | JpaConsumer | 125 - org.apache.camel.camel-core - 2.12.0 | Consumer Consumer[jpa://net.lr.tutorial.karaf.camel.jpa2jms.model.Person?consumer.delay=3500] failed polling endpoint: Endpoint[jpa://net.lr.tutorial.karaf.camel.jpa2jms.model.Person?consumer.delay=3500]. Will try again at next poll. Caused by: [org.apache.openjpa.persistence.ArgumentException - An error occurred while parsing the query filter select x from Person x. Error message: The name Person is not a recognized entity or identifier. Perhaps you meant Person, which is a close match. Known entity names: [Person]] openjpa-2.1.1-r422266:1148538 nonfatal user error org.apache.openjpa.persistence.ArgumentException: An error occurred while parsing the query filter select x from Person x. Error message: The name Person is not a recognized entity or identifier. Perhaps you meant Person, which is a close match. Known entity names: [Person] Any ideas? Sean -- View this message in context: http://openjpa.208410.n2.nabble.com/org-apache-openjpa-persistence-ArgumentException-An-error-occurred-while-parsing-the-query-filter-se-tp7585976.html Sent from the OpenJPA Users mailing list archive at Nabble.com. -- *Rick Curtis*
Re: [org.apache.openjpa.persistence.ArgumentException - An error occurred while parsing the query filter select x from Person x. Error message: The name Person is not a recognized entity or identi
Hi Rick, Here's the contents of my persistence.xml persistence xmlns=http://java.sun.com/xml/ns/persistence; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=1.0 persistence-unit name=person2 transaction-type=JTA jta-data-sourceosgi:service/javax.sql.XADataSource/(osgi.jndi.service.name=jdbc/derbydsxa)/jta-data-source classnet.lr.tutorial.karaf.camel.jpa2jms.model.Person/class exclude-unlisted-classestrue/exclude-unlisted-classes properties property name=openjpa.jdbc.SynchronizeMappings value=buildSchema/ property name=openjpa.jdbc.DBDictionary value=derby/ /properties /persistence-unit /persistence Regards, Sean -- View this message in context: http://openjpa.208410.n2.nabble.com/org-apache-openjpa-persistence-ArgumentException-An-error-occurred-while-parsing-the-query-filter-se-tp7585976p7585979.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
DataCache Performance Issues
Hello, We’re currently migrating an application from OpenJPA 1.2.2 to OpenJPA 2.3.0, and have found that DataCache efficacy in our application declines significantly from 1.2.2 to 2.3.0, to the point where our overall system performance has declined by about 25% with the version upgrade. We’ve found that we can restore DataCache performance to 1.2.2 levels by re-applying OPENJPA-2285https://issues.apache.org/jira/browse/OPENJPA-2285, which was rolled back due to an “internal test regression” issue. The behaviour we’ve found is this: Given: An entity Foo, with fields [a, b, c]. Foo-1 is loaded into the datacache using a fetch group that loads fields [a, b]. When: A query is executed that loads Foo-1 using fields [b,c]. This query is executed twice in succession, using two different EntityManagers. Then: In OpenJPA 2.3.0, both queries result in a SQL query being run to load the value of field c. In OpenJPA 1.2.2, only the first query results in a SQL query being run to load the value of field c. The second query is serviced from cache. Expected: The OpenJPA 1.2.2 behaviour seems more consistent with expected cache behaviour. The cache cannot be expected to successfully fulfill the request on the first invocation – but it should be able to fulfill it on all subsequent invocations. The first question is, what should OpenJPA 2’s behaviour be in this circumstance? OPENJPA-2285https://issues.apache.org/jira/browse/OPENJPA-2285 merges the new loaded fields into the original cached entity and recaches the entity. OpenJPA 1.2.2 does a similar thing, except that it rejects the merge if the new entity has an earlier version than the cached entity. Note that merging still occurs in OpenJPA 1.2.2 if the new entity has a later version than the cached entity. Another question we have is what exactly was the “internal test regression” that caused the rollback? Some potential solutions: 1. Merge cached and loaded data as per OPENJPA-2285/OpenJPA 1.2.2. This minimizes database operations required. On the other hand, the merge of cached and non-cached data raises the possibility of entities with “mixed” data from various versions. It’s probably best to reject the object entirely if a version conflict is detected and reload the entire object from the db (and recache) in that instance. 2. Load object from db using the query’s fetch group and recache. Instead of merging cached fields and db loaded fields, OpenJPA could load the entire object using the query’s fetch group. This object should be in a consistent state, and the object in data cache could be replaced with the newly loaded object. The disadvantage would be if there are two different queries being run for the same entity, one with the fetch group [a, b] and another with the fetch group [b,c], then the object in cache will “whipsaw” back and forth between representations. This also results in more db access than option #1. 3. Load object from db using the superset of the query’s fetch group and the datacache’s fetch group and recache. Instead of merging cached fields and db loaded fields, OpenJPA could load the entire object using the union of the query’s fetch group and the cached entities’ fetch group. This object should be in a consistent state, and the object in data cache could be replaced with the newly loaded object. The disadvantage would be it’s hard to see how this could reliably extend to entities related to the original entity that are loaded as part of the query. However, it avoids the whipsaw problems in option #2. This option also results in the most db access, at least initially. 4. Remove incomplete entities from cache. Merge cached and loaded data together as is done currently, but remove the cached entity afterwards. This isn’t much of a solution, but at least a sparsely loaded entity doesn’t have the potential to degrade the cache indefinitely… 5. Some ability to enable one or more of the solutions via a config option, if none of these solutions are considered acceptable for “core” use. If there’s agreement on what behaviour folks would like to see, I’d be happy to submit a patch. Cheers, Jeff [http://elasticpath.com/images/ep.gif] Jeff Oh, Sr. Software Engineer Phone: 604.408.8078 ext. 104 Email: jeff...@elasticpath.commailto:jeff...@elasticpath.com Elastic Path Software Inc. Web elasticpath.com http://www.elasticpath.com/ | Blog getelastic.com http://www.getelastic.com/ | Twitter twitter.com/elasticpath http://www.twitter.com/elasticpath Careers elasticpath.com/jobshttp://www.elasticpath.com/jobs | Community grep.elasticpath.com http://grep.elasticpath.com/ Confidentiality Notice: This message is intended only for the use of the designated addressee(s), and may contain information that is privileged, confidential and exempt from disclosure. Any unauthorized viewing, disclosure, copying, distribution or use of information contained in this e-mail is
