[jira] Commented: (OPENJPA-1792) Drop JDK5 support starting with OpenJPA 2.1
[ https://issues.apache.org/jira/browse/OPENJPA-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003861#comment-13003861 ] Mark Struberg commented on OPENJPA-1792: +1 for dropping the java5 support in 2.2.x. I honestly don't know anyone using it still. They are either still on 1.4.2 or 1.6 Drop JDK5 support starting with OpenJPA 2.1 --- Key: OPENJPA-1792 URL: https://issues.apache.org/jira/browse/OPENJPA-1792 Project: OpenJPA Issue Type: Task Components: build / infrastructure Affects Versions: 2.1.0 Reporter: Donald Woods Assignee: Donald Woods Fix For: 2.1.0 There were no -1 votes on the discussion thread to drop JDK5 support from trunk (2.1) so I'll move ahead with it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Help with Cassandra JPA plugin
Some general comments... Extending the OpenJPA kernel for JDO is definitely doable. The original code base (BEA's Kodo) had a JDO personality, but it was never contributed to the OpenJPA project. At least for a period of time (I don't know if it still is), BEA and then Oracle continued to support this JDO personality internally. So, I know it's a doable endeavor... The other bit of news is that our own Craig Russell is a bit of JDO expert... :-) And, he might even know a thing or two about the JDO personality. Good luck, Kevin On Mon, Mar 7, 2011 at 10:22 PM, Todd Nine t...@spidertracks.com wrote: Hi guys, I've previously developed a JDO plugin for Cassandra using Datanucleus. I'm now helping the datastax guys develop the JPA plugin using open JPA. I'm having some trouble I would use a hand with from developers. Current version 2.1.0 Issue 1: Defining an identity generator at the plugin level. Most of our users will want a TimeUUID generated as the default entity Id. We do not want to do this as a string, but rather want to use the actual UUID object. As you can see from my code here, I'm defining the generator at the entity level. Since this will be a default use case for a lot of our users, I want to make it a standard part of our plugin. https://github.com/riptano/hector-jpa/blob/master/src/test/java/com/datastax/hectorjpa/bean/TimeUuidEntity.java and https://github.com/riptano/hector-jpa/blob/master/src/main/java/com/datastax/hectorjpa/sequence/TimeUuid.java Issue 2: Allocate is never invoked on my sequence generator, I'm assuming this is due to incorrect setup that will be resolved in issue 1. Issue 3: Do I need to synchronize the next call internally in my Sequence generator? Given the high throughput of our JPA clients, I don't want to accidentally return the same UUID to multiple callers. Thanks, -- todd SENIOR SOFTWARE ENGINEER todd nine| spidertracks ltd | 117a the square po box 5203 | palmerston north 4441 | new zealand P: +64 6 353 3395 E: t...@spidertracks.co.nz W: www.spidertracks.com
Re: Help with Cassandra JPA plugin
Hey Kevin, Thanks for the reply. To be clear, I'm not actually creating a JDO plugin. Rather I'm migrating what I've done from JDO to JPA. The demand for JPA is much greater in the community, and we would prefer to use it here as well. My biggest hurdle is finding good developer documentation to allow me to create the best plugin possible using open JPA. If you can give me any guidance on the issues below for a JPA only implementation, I would really appreciate it. Thanks, Todd On Tue, 2011-03-08 at 13:58 -0600, Kevin Sutter wrote: Some general comments... Extending the OpenJPA kernel for JDO is definitely doable. The original code base (BEA's Kodo) had a JDO personality, but it was never contributed to the OpenJPA project. At least for a period of time (I don't know if it still is), BEA and then Oracle continued to support this JDO personality internally. So, I know it's a doable endeavor... The other bit of news is that our own Craig Russell is a bit of JDO expert... :-) And, he might even know a thing or two about the JDO personality. Good luck, Kevin On Mon, Mar 7, 2011 at 10:22 PM, Todd Nine t...@spidertracks.com wrote: Hi guys, I've previously developed a JDO plugin for Cassandra using Datanucleus. I'm now helping the datastax guys develop the JPA plugin using open JPA. I'm having some trouble I would use a hand with from developers. Current version 2.1.0 Issue 1: Defining an identity generator at the plugin level. Most of our users will want a TimeUUID generated as the default entity Id. We do not want to do this as a string, but rather want to use the actual UUID object. As you can see from my code here, I'm defining the generator at the entity level. Since this will be a default use case for a lot of our users, I want to make it a standard part of our plugin. https://github.com/riptano/hector-jpa/blob/master/src/test/java/com/datastax/hectorjpa/bean/TimeUuidEntity.java and https://github.com/riptano/hector-jpa/blob/master/src/main/java/com/datastax/hectorjpa/sequence/TimeUuid.java Issue 2: Allocate is never invoked on my sequence generator, I'm assuming this is due to incorrect setup that will be resolved in issue 1. Issue 3: Do I need to synchronize the next call internally in my Sequence generator? Given the high throughput of our JPA clients, I don't want to accidentally return the same UUID to multiple callers. Thanks, -- todd SENIOR SOFTWARE ENGINEER todd nine| spidertracks ltd | 117a the square po box 5203 | palmerston north 4441 | new zealand P: +64 6 353 3395 E: t...@spidertracks.co.nz W: www.spidertracks.com
[jira] Commented: (OPENJPA-1787) Bean validation fails merging a new entity
[ https://issues.apache.org/jira/browse/OPENJPA-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004237#comment-13004237 ] Michael Dick commented on OPENJPA-1787: --- The main problem with your proposed solution is that it would change the way merge works. EntityManager.merge creates a new copy of the entity and it's the copy of the entity that becomes part of the persistence context - not the entity you passed in. Your change would eliminate the copy. I think the real issue here is that the data hasn't been copied into the new instance before validation occurs. I'm not familiar with this code path, and I haven't had a chance to try your testcase yet, but I'd start by looking at the code where we copy the fields into a new instance. Bean validation fails merging a new entity -- Key: OPENJPA-1787 URL: https://issues.apache.org/jira/browse/OPENJPA-1787 Project: OpenJPA Issue Type: Bug Components: jpa, kernel Affects Versions: 2.0.1, 2.1.0, 2.2.0 Reporter: Oliver Ringel Priority: Critical Attachments: com.example.TestEmployeeDAO.txt, openjpa-1787.tar, testcase-openjpa-1787.tar The bean validation is not working correctly If you try to merge a new entity. EntityManager em = entityManagerFactory.createEntityManager(); Person person = new Person(); person.setName(Oliver); // Employee.name is annotated @NotNull person = em.merge(person); you get a ConstraintValidationException, although name is set. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-1956) Add an error message in case of bad class and/or attribute in fetchPlan.addField(class, field);
[ https://issues.apache.org/jira/browse/OPENJPA-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004238#comment-13004238 ] Michael Dick commented on OPENJPA-1956: --- +1. Will take a look when I get a few free cycles. Add an error message in case of bad class and/or attribute in fetchPlan.addField(class, field); --- Key: OPENJPA-1956 URL: https://issues.apache.org/jira/browse/OPENJPA-1956 Project: OpenJPA Issue Type: Improvement Components: validation Reporter: Jean-Baptiste Briaud - Novlog 2 persistent classes : A B extends A. A have the primary key : id. I was using fetch plan to include id but with the wrong class. I badly added a fetch plan for B.class, id. id was null, because it was finally not included in the fetch plan. This is OK but when I build the fetch plan, why not raising an error message with something like : no attribute id on B. It took me ages to find my error. After I added the correct fetch plan : A.class, id, everything works fine. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Help with Cassandra JPA plugin
Hi Todd, Okay, now I understand your question. I should read more closely... :-) Looking at your code, nothing is jumping out at me as being incorrect. You have implemented the Seq interface, and it looks like you have designated the sequenceName correctly. We have a junit test case that does something very similar. This test is also testing out UUID generation, so that might be of interest as well. Check this out for an example: https://fisheye6.atlassian.com/browse/~br=trunk/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/generationtype/TestGeneratedValues.java?hb=true https://fisheye6.atlassian.com/browse/~br=trunk/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/generationtype/GeneratedValues.java?r=777135 https://fisheye6.atlassian.com/browse/~br=trunk/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/generationtype/CustomSeq.java?r=777135r=757278 Also, our UUID generation does lock and synchronize to protect certain code paths. You'll probably need to do something similar. Here's an example of our code: https://fisheye6.atlassian.com/browse/~br=trunk/openjpa/trunk/openjpa-lib/src/main/java/org/apache/openjpa/lib/util/UUIDGenerator.java?r=777135r=757278r=792592 Good luck, Kevin On Tue, Mar 8, 2011 at 2:46 PM, Todd Nine t...@spidertracks.com wrote: Hey Kevin, Thanks for the reply. To be clear, I'm not actually creating a JDO plugin. Rather I'm migrating what I've done from JDO to JPA. The demand for JPA is much greater in the community, and we would prefer to use it here as well. My biggest hurdle is finding good developer documentation to allow me to create the best plugin possible using open JPA. If you can give me any guidance on the issues below for a JPA only implementation, I would really appreciate it. Thanks, Todd On Tue, 2011-03-08 at 13:58 -0600, Kevin Sutter wrote: Some general comments... Extending the OpenJPA kernel for JDO is definitely doable. The original code base (BEA's Kodo) had a JDO personality, but it was never contributed to the OpenJPA project. At least for a period of time (I don't know if it still is), BEA and then Oracle continued to support this JDO personality internally. So, I know it's a doable endeavor... The other bit of news is that our own Craig Russell is a bit of JDO expert... :-) And, he might even know a thing or two about the JDO personality. Good luck, Kevin On Mon, Mar 7, 2011 at 10:22 PM, Todd Nine t...@spidertracks.com wrote: Hi guys, I've previously developed a JDO plugin for Cassandra using Datanucleus. I'm now helping the datastax guys develop the JPA plugin using open JPA. I'm having some trouble I would use a hand with from developers. Current version 2.1.0 Issue 1: Defining an identity generator at the plugin level. Most of our users will want a TimeUUID generated as the default entity Id. We do not want to do this as a string, but rather want to use the actual UUID object. As you can see from my code here, I'm defining the generator at the entity level. Since this will be a default use case for a lot of our users, I want to make it a standard part of our plugin. https://github.com/riptano/hector-jpa/blob/master/src/test/java/com/datastax/hectorjpa/bean/TimeUuidEntity.java and https://github.com/riptano/hector-jpa/blob/master/src/main/java/com/datastax/hectorjpa/sequence/TimeUuid.java Issue 2: Allocate is never invoked on my sequence generator, I'm assuming this is due to incorrect setup that will be resolved in issue 1. Issue 3: Do I need to synchronize the next call internally in my Sequence generator? Given the high throughput of our JPA clients, I don't want to accidentally return the same UUID to multiple callers. Thanks, -- todd SENIOR SOFTWARE ENGINEER todd nine| spidertracks ltd | 117a the square po box 5203 | palmerston north 4441 | new zealand P: +64 6 353 3395 E: t...@spidertracks.co.nz W: www.spidertracks.com
Re: Help with Cassandra JPA plugin
Awesome. Thanks for the help Kevin. I have a couple of follow up questions. Allocate doesn't appear to do anything in your test custom sequence either. Is there any way to get the Open JPA framework to invoke it without allocating during the next call? https://fisheye6.atlassian.com/browse/~br=trunk/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/generationtype/CustomSeq.java?r=777135r=757278 As per this example https://fisheye6.atlassian.com/browse/~br=trunk/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/generationtype/GeneratedValues.java?r=777135 We're doing the same thing. Is it possible to register the sequence generator we create globally with the Open JPA framework so that users can simply use the annotations like this without the need to declare a @SequenceGenerator? @Id @GeneratedValue(strategy=time-uuid) private UUID id; Thanks, Todd On Tue, 2011-03-08 at 17:21 -0600, Kevin Sutter wrote: Hi Todd, Okay, now I understand your question. I should read more closely... :-) Looking at your code, nothing is jumping out at me as being incorrect. You have implemented the Seq interface, and it looks like you have designated the sequenceName correctly. We have a junit test case that does something very similar. This test is also testing out UUID generation, so that might be of interest as well. Check this out for an example: https://fisheye6.atlassian.com/browse/~br=trunk/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/generationtype/TestGeneratedValues.java?hb=true https://fisheye6.atlassian.com/browse/~br=trunk/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/generationtype/GeneratedValues.java?r=777135 https://fisheye6.atlassian.com/browse/~br=trunk/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/generationtype/CustomSeq.java?r=777135r=757278 Also, our UUID generation does lock and synchronize to protect certain code paths. You'll probably need to do something similar. Here's an example of our code: https://fisheye6.atlassian.com/browse/~br=trunk/openjpa/trunk/openjpa-lib/src/main/java/org/apache/openjpa/lib/util/UUIDGenerator.java?r=777135r=757278r=792592 Good luck, Kevin On Tue, Mar 8, 2011 at 2:46 PM, Todd Nine t...@spidertracks.com wrote: Hey Kevin, Thanks for the reply. To be clear, I'm not actually creating a JDO plugin. Rather I'm migrating what I've done from JDO to JPA. The demand for JPA is much greater in the community, and we would prefer to use it here as well. My biggest hurdle is finding good developer documentation to allow me to create the best plugin possible using open JPA. If you can give me any guidance on the issues below for a JPA only implementation, I would really appreciate it. Thanks, Todd On Tue, 2011-03-08 at 13:58 -0600, Kevin Sutter wrote: Some general comments... Extending the OpenJPA kernel for JDO is definitely doable. The original code base (BEA's Kodo) had a JDO personality, but it was never contributed to the OpenJPA project. At least for a period of time (I don't know if it still is), BEA and then Oracle continued to support this JDO personality internally. So, I know it's a doable endeavor... The other bit of news is that our own Craig Russell is a bit of JDO expert... :-) And, he might even know a thing or two about the JDO personality. Good luck, Kevin On Mon, Mar 7, 2011 at 10:22 PM, Todd Nine t...@spidertracks.com wrote: Hi guys, I've previously developed a JDO plugin for Cassandra using Datanucleus. I'm now helping the datastax guys develop the JPA plugin using open JPA. I'm having some trouble I would use a hand with from developers. Current version 2.1.0 Issue 1: Defining an identity generator at the plugin level. Most of our users will want a TimeUUID generated as the default entity Id. We do not want to do this as a string, but rather want to use the actual UUID object. As you can see from my code here, I'm defining the generator at the entity level. Since this will be a default use case
[jira] Created: (OPENJPA-1957) XML overriding column names for ArrayList attributes causes exception.
XML overriding column names for ArrayList attributes causes exception.
--
Key: OPENJPA-1957
URL: https://issues.apache.org/jira/browse/OPENJPA-1957
Project: OpenJPA
Issue Type: Bug
Components: jdbc
Affects Versions: 2.1.0, 2.0.1, 1.2.2
Reporter: Heath Thomann
Assignee: Heath Thomann
Priority: Minor
Take an entity class similar to the following:
public class MyEntity implements Serializable {
protected String _id;
protected ArrayListString myStrings = new ArrayListString();
...
and a corresponding XML mapping in orm.xml:
entity class=somepackage.MyEntity access=FIELD
table name=MY_TABLE/
attributes
id name=_id
column name=MYENTITY_ID nullable=false /
/id
basic name=myStrings
column name=MY_STRINGS/
lob/
/basic
/attributes
/entity
With this configuration, the following exception can occur:
org.apache.openjpa.persistence.ArgumentException: You have supplied columns for
somepackage.MyEntity.myStringselement:class java.lang.String, but this
mapping cannot have columns in this context.
at
org.apache.openjpa.jdbc.meta.MappingInfo.assertNoSchemaComponents(MappingInfo.java:327)
at
org.apache.openjpa.jdbc.meta.strats.HandlerFieldStrategy.map(HandlerFieldStrategy.java:77)
at
org.apache.openjpa.jdbc.meta.FieldMapping.setStrategy(FieldMapping.java:121)
at
org.apache.openjpa.jdbc.meta.RuntimeStrategyInstaller.installStrategy(RuntimeStrategyInstaller.java:80)
at
org.apache.openjpa.jdbc.meta.FieldMapping.resolveMapping(FieldMapping.java:454)
at
org.apache.openjpa.jdbc.meta.FieldMapping.resolve(FieldMapping.java:419)
at
org.apache.openjpa.jdbc.meta.ClassMapping.resolveNonRelationMappings(ClassMapping.java:881)
at
org.apache.openjpa.jdbc.meta.MappingRepository.prepareMapping(MappingRepository.java:418)
..
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
