RE: OneToOne Broken
Interesting. I bet that the problem is that you directly set the public field in your test code, but you didn't run the OpenJPA bytecode processor over the test code, so OpenJPA didn't intercept the field set. If you want this type of use case, OpenJPA needs to know about (and process) the classes that directly access persistent fields, so that it can eagerly track changes. How are you deploying? It might make sense to change our ClassTransformer impl to automatically process all classes in a deployed Java EE archive by default rather than just the ones marked @Entity and @MappedSuperclass. For people who are relying on automatic enhancement, this certainly is a surprising situation to end up in. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED] Sent: Sunday, December 10, 2006 8:38 AM To: open-jpa-dev@incubator.apache.org Subject: Re: OneToOne Broken On Dec 9, 2006, at 9:01 PM, Craig L Russell wrote: Hi Dain, You don't have a relationship from Article to Magazine, so it's a unidirectional mapping. Are you sure? If you uncomment the line that is commented out in testResourceLocal it works. I assume that means that I do have a relationship since OpenJPA is correctly filling in the fk column. Add a Magazine mag; field in Article and see if it starts working. That is the way I originally had the test code, but I wanted to create the smallest test code possible, so I remove it. Anyway, I just added a public Magazine magazine field to the Article class and added this to the test-mappings.xml file: one-to-one name=magazine mapped-by=coverArticle/ ...and it still fails. You will also need to identify the owner of the relationship in order to make it work at all. I thought when I declare the join-column in the Magazine.coverArticle field, that made it the owner. How do I declare the owner of the relationship? Just a note, JPA does not do well with unidirectional relationships. There is more unspecified than specified there. OK. I'll avoid them And public fields are JPA for evil. I agree, but wanted the smallest test code possible :) Craig Thanks Craig, -dain
RE: Collection (or Map) relationships and null
If you have a null indicator for the collection / map field, then OpenJPA will preserve the null-ness. Otherwise, the default value will be dictated by what your no-args constructor does (or, equivalently, what your member field initializations do). -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED] Sent: Monday, December 11, 2006 10:53 AM To: open-jpa-dev@incubator.apache.org Subject: Collection (or Map) relationships and null When I access a collection (or Map) valued relation field when will the field value be null and when won't it be null? In CMP 2, it was gaurenteed that the field was always non-null, but I'd expect with OpenJPA that it is at least null form new() to em.persist(). Also, what happens when someone puts a bad value on the Collection (or Map). For example, a null in the collection, or an entry in the map where the pk doesn't match the bean added. -dain
Re: Collection (or Map) relationships and null
On Dec 11, 2006, at 2:09 PM, Patrick Linskey wrote: If you have a null indicator for the collection / map field, then OpenJPA will preserve the null-ness. What's that? I see you can specify a column as being not nullable but I don't see anything in the spec about null and collections. Otherwise, the default value will be dictated by what your no-args constructor does (or, equivalently, what your member field initializations do). What about for a bean acquired via load? Will JPA set an empty collection into the field, or do I need to add initialize the field? Actually, maybe just skip all that :) What is the best practice for Collection and Map fields? Also what about this question: Also, what happens when someone puts a bad value on the Collection (or Map). For example, a null in the collection, or an entry in the map where the pk doesn't match the bean added. Thanks, -dain
RE: Flush all caches?
There's certainly nothing wrong with that approach. However, the situation is not as simple as it seems. When used in a JTA environment, by default an EntityManager will use a transactional persistence context. This means that each transaction essentially automatically gets a new EntityManager under the covers, and each operation that happens outside a transaction happens in its own under-the-covers-EntityManager as well. So, if you're in a JTA environment and haven't configured yourself to use extended persistence contexts, then there's really no difference between getting a new EM or reusing the existing one. Think of a transactional-PC JTA EntityManager as a proxy, rather than a real EM. Interesting. Is this something the Jee server manages for you or is this something inherently in OpenJPA? The reason I ask is because I'm not using server managed entity managers. Instead, I am constructing them directly using a PersistenceUnitInfo. Interesting indeed. It's behavior that can be implemented just by an appserver, but Kodo also has properties to handle the work internally. You might be triggering that behavior by using a PUInfo to initialize; how are you doing that exactly? The spec defines that the way to get application-managed EMs is via a call to Persistence.createEntityManager(). Container-managed EMs come from PersistenceProvider.createContainerEntityManager() (or something like that). I'm not sure where OpenJPA's persistence context defaults get applied in which way. This gets configured via the openjpa.AutoDetach property. In any event, I kinda feel like there's a bit of a disconnect between my assumptions and yours; lemme know if you've got the same feeling. Not sure, but let me fill you in on what I'm doing. To start with, I'm trying to write a few small example test cases for simple beans, one-to-one, one-to-many and many-to-many. I've run into enough set backs while coding my real stuff that I want simple standalone tests to verify that OpenJPA is working and my code is wrong, which has always been the case so far :) One common problem I have run into is that my beans get cached in the EMF and my tests pass even though the database is not being updated, so I have tests that muck with the database directly to assure that OpenJPA is grabbing the real data. This is why I keep asking about caches and clustering (since my JDBC code looks like a clustered server to OpenJPA). It's really surprising that the cache would get updated but the database would not. The cache should not be populated until after the SQL statements are issued. Are you seeing things in the database that do not correspond with what you see in the SQL logs? I'm really working on a replacement for the OpenEJB Castor CMP container that uses OpenJPA instead. I'm just hacking in the CMRs right now, hence all the relationship questions. I hope to have the basics done in a few days. Ah. That probably explains it. JPA is designed kinda to assume that you manage both sides of relationships in your own domain code, since it can get tricky to do the right thing with raw exposed lists etc. OpenJPA does have some inverse management capabilities that go a certain extent towards the same behavior as CMR in EJB2. Check out the docs on the openjpa.InverseManager property. -Patrick ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: Collection (or Map) relationships and null
-Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED] Sent: Monday, December 11, 2006 2:23 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Collection (or Map) relationships and null On Dec 11, 2006, at 2:09 PM, Patrick Linskey wrote: If you have a null indicator for the collection / map field, then OpenJPA will preserve the null-ness. What's that? I see you can specify a column as being not nullable but I don't see anything in the spec about null and collections. Looking at things, I'm not 100% how to configure via JPA. It could be via the org.apache.openjpa.persistence.jdbc.EmbeddedMapping annotation (note the nullIndicator property there) -- in Kodo parlance, collections and maps themselves are 'embedded', and it's their values that are typically not embedded. But our docs certainly don't make that clear currently. Otherwise, the default value will be dictated by what your no-args constructor does (or, equivalently, what your member field initializations do). What about for a bean acquired via load? Will JPA set an empty collection into the field, or do I need to add initialize the field? We'll call the no-args constructor in the object to create the new record, and then populate things from the DB. If you don't have a no-args constructor, we create one for you during enhancement. When we auto-gen one, I don't remember whether we attempt to emulate initialization that you do elsewhere. Actually, maybe just skip all that :) What is the best practice for Collection and Map fields? If you want to distinguish between null and not-null, use indicators. Otherwise, initialize them to non-null values. Also what about this question: Also, what happens when someone puts a bad value on the Collection (or Map). For example, a null in the collection, or an entry in the map where the pk doesn't match the bean added. No idea. If you've got database constraints in place, you'll at least get an exception at commit time. -Patrick ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
updating docs; unifying websites
Hi, I noticed that the latest docs on our website is 0.9.0. Do we have a process in place for updating them at this point? Also, I noticed that I could navigate to docs either from the main site (http://incubator.apache.org/projects/openjpa or http://incubator.apache.org/openjpa), or via the wiki. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Collection (or Map) relationships and null
1. Loaded instances last stored with a null or empty collection/map are restored with an empty collection/map, period. You can ignore all the talk about null indicators. 2. Instances you construct yourself will maintain their null vs. empty field values at least until persist. Beyond that you shouldn't rely on null collections and maps remaining null -- they might become empty. 3. Pinaki's tip shows how to tell OpenJPA to throw an exception if you attempt to add an entity of the wrong type to a persistent collection/map field. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: Flush all caches?
The spec defines that the way to get application-managed EMs is via a call to Persistence.createEntityManager(). Container-managed EMs come from PersistenceProvider.createContainerEntityManager() (or something like that). App managed em suck because you can't use JTA transactions. Also I'm targeting an app managed environment, but I don't want to run in it with small tests. What gives you that impression? -Patrick ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: updating docs; unifying websites
Oops ... I forgot to do that when I released. I've uploaded them and added the link to: http://cwiki.apache.org/openjpa/documentation.html It takes a little while for the static update to propagate to the server. Once the synchronization happens, I'll update the building page of the wiki to add in instructions for uplaoding the docs. On Dec 11, 2006, at 2:59 PM, Patrick Linskey wrote: Hi, I noticed that the latest docs on our website is 0.9.0. Do we have a process in place for updating them at this point? Also, I noticed that I could navigate to docs either from the main site (http://incubator.apache.org/projects/openjpa or http://incubator.apache.org/openjpa), or via the wiki. -Patrick -- Patrick Linskey BEA Systems, Inc. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: extending the life of a LRS query
Hi Patrick, Thanks for your detailed reply. Patrick Linskey wrote: If what you're looking for is to hold the cursor to the DB open across multiple requests, you'll need to create an extended-persistence-context EM (either via a stateful session bean or via using a non-JTA entity manager, obtained through an EMF), and then do the query in that EM and bind the query into session state somewhere. Of course, all the normal cautions about keeping database connections open across multiple requests apply. I guess that was the obvious solution. I subscribed to the one-pm-per-request pattern so long ago that I've even forgotten why. This works very well for me. I can bind my list to jsf dataTable and scroll through the results as they're loaded from the database. I think you just improved my quality of life :) If you're just looking to page through results for a search-result-style listing, you might be interested in the JPA Query.setFirstResult() and Query.setMaxResults() calls -- these allow for efficient (but non-isolated) paging through queries. Don't forget to add an ordering to your query when you do this, of course. Oh, and OpenJPA is smart about using range data in the query cache. I tried this out also and it seems to be quite efficient (not all orm products are as good). Not as convenient as the LRS, but good to know that OpenJPA is smart about ranges. Cheers, Roger -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED] Sent: Saturday, December 09, 2006 9:24 AM To: open-jpa-dev@incubator.apache.org Subject: Re: extending the life of a LRS query I am by no means an OpenJPA expert, but I did see something related to this when reading the docs yesterday. OpenJPA has a QueryResultsCache where it keeps the results of a query so if you run the query again you get the same results (I'm not sure if that is what you want). Here is the code from the docs: OpenJPAEntityManagerFactory oemf = OpenJPAPersistence.cast(emf); QueryResultCache qcache = oemf.getQueryResultCache(); EntityManager em = emf.createEntityManager(); Query pinQuery = em.createQuery(...). setParameter(0, paramVal0). setParameter(1, paramVal1); qcache.pin(pinQuery); Query unpinQuery = em.createQuery(...). setParameter(0, paramVal0). setParameter(1, paramVal1); qcache.unpin(unpinQuery); Hope that helped. -dain On Dec 8, 2006, at 8:04 PM, roger.keays wrote: Hi, I'm trying to use OpenJPA's fetch plan extensions to have a query return a large result set. It seems to work okay, except that the LRS gets closed / detached with the EntityManager, which only makes it useful for one request. Is it possible to have the LRS stay open after the em has been disposed? Thanks, Roger -- View this message in context: http://www.nabble.com/extending-the- life-of-a-LRS-query-tf2784490.html#a7769269 Sent from the open-jpa-dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/extending-the-life-of-a-LRS-query-tf2784490.html#a7825755 Sent from the open-jpa-dev mailing list archive at Nabble.com.
RE: Get primary key from persistent bean
This is a major hole in the JPA spec if you ask me. Once upon a time, there was a spec called JDO. It had a API javax.jdo.JDOHelper.getObjectId(Object pc); I think it got left out while copying ;) Pinaki Poddar BEA Systems 415.402.7317 ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Get primary key from persistent bean
Dain- Note that you could always introspect on the class and look for the @Id annotation, and get the value of the Field/Method on which the annotation resides. This is pretty heavy-handed, and doesn't work for XML mappings, but it is one possible way to do this without making assumptions about the underlying vendor. On Dec 11, 2006, at 5:45 PM, Dain Sundstrom wrote: On Dec 11, 2006, at 5:34 PM, Craig L Russell wrote: Hi Dain, How about Object pk = bean.getId(); That implies that every persistent bean implements getId(). That would work find for the beans I write but not for beans other write. This is a major hole in the JPA spec if you ask me. -dain
Re: Get primary key from persistent bean
Hi Dain, I've never seen an @Entity without an @Id annotation. I don't believe it is a valid JPA mapping without an @Id. That said, it's not required to be named Id. So are you writing a framework or sample code? For a framework, it would be nice to be portable. For sample code, who cares? Craig On Dec 11, 2006, at 5:45 PM, Dain Sundstrom wrote: On Dec 11, 2006, at 5:34 PM, Craig L Russell wrote: Hi Dain, How about Object pk = bean.getId(); That implies that every persistent bean implements getId(). That would work find for the beans I write but not for beans other write. This is a major hole in the JPA spec if you ask me. -dain Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: extending the life of a LRS query
Hi, Note that not all databases support efficient FirstResult and MaxResults implementations. But even those that don't have built-in support for skipping n rows, the usual use case is to skip where n is small. The most frequent case is FirstResult == 0 followed in rapidly descending order n, 2*n, 3*n, and vanishingly small. And most databases will be reasonably efficient for these common cases. Craig On Dec 11, 2006, at 5:35 PM, roger.keays wrote: Hi Patrick, Thanks for your detailed reply. Patrick Linskey wrote: If what you're looking for is to hold the cursor to the DB open across multiple requests, you'll need to create an extended-persistence- context EM (either via a stateful session bean or via using a non-JTA entity manager, obtained through an EMF), and then do the query in that EM and bind the query into session state somewhere. Of course, all the normal cautions about keeping database connections open across multiple requests apply. I guess that was the obvious solution. I subscribed to the one-pm-per-request pattern so long ago that I've even forgotten why. This works very well for me. I can bind my list to jsf dataTable and scroll through the results as they're loaded from the database. I think you just improved my quality of life :) If you're just looking to page through results for a search-result- style listing, you might be interested in the JPA Query.setFirstResult() and Query.setMaxResults() calls -- these allow for efficient (but non-isolated) paging through queries. Don't forget to add an ordering to your query when you do this, of course. Oh, and OpenJPA is smart about using range data in the query cache. I tried this out also and it seems to be quite efficient (not all orm products are as good). Not as convenient as the LRS, but good to know that OpenJPA is smart about ranges. Cheers, Roger -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED] Sent: Saturday, December 09, 2006 9:24 AM To: open-jpa-dev@incubator.apache.org Subject: Re: extending the life of a LRS query I am by no means an OpenJPA expert, but I did see something related to this when reading the docs yesterday. OpenJPA has a QueryResultsCache where it keeps the results of a query so if you run the query again you get the same results (I'm not sure if that is what you want). Here is the code from the docs: OpenJPAEntityManagerFactory oemf = OpenJPAPersistence.cast(emf); QueryResultCache qcache = oemf.getQueryResultCache(); EntityManager em = emf.createEntityManager(); Query pinQuery = em.createQuery(...). setParameter(0, paramVal0). setParameter(1, paramVal1); qcache.pin(pinQuery); Query unpinQuery = em.createQuery(...). setParameter(0, paramVal0). setParameter(1, paramVal1); qcache.unpin(unpinQuery); Hope that helped. -dain On Dec 8, 2006, at 8:04 PM, roger.keays wrote: Hi, I'm trying to use OpenJPA's fetch plan extensions to have a query return a large result set. It seems to work okay, except that the LRS gets closed / detached with the EntityManager, which only makes it useful for one request. Is it possible to have the LRS stay open after the em has been disposed? Thanks, Roger -- View this message in context: http://www.nabble.com/extending-the- life-of-a-LRS-query-tf2784490.html#a7769269 Sent from the open-jpa-dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/extending-the- life-of-a-LRS-query-tf2784490.html#a7825755 Sent from the open-jpa-dev mailing list archive at Nabble.com. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Get primary key from persistent bean
On Dec 11, 2006, at 6:03 PM, Craig L Russell wrote: Hi Dain, I've never seen an @Entity without an @Id annotation. I don't believe it is a valid JPA mapping without an @Id. That said, it's not required to be named Id. I'm not using annotations at all. Everything is done in the mappings xml. So are you writing a framework or sample code? For a framework, it would be nice to be portable. For sample code, who cares? I'm doing both. If I determine that getting the pk from JPA is necessary for the framework, I'm just add another method to my non- portable jpa wrapper :) BTW another thing that JPA needs is an equivalent of the OpenJPA LifecycleListener. The interceptor stuff doesn't cut it since beans can override the interception and it is just a PIA to get your interceptor added to ever bean. -dain
RE: extending the life of a LRS query
FWIW, OpenJPA uses SQL syntax (rather than JDBC) for ranges for all databases but JDataStore, to my knowledge. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, December 11, 2006 6:11 PM To: open-jpa-dev@incubator.apache.org Subject: Re: extending the life of a LRS query Hi, Note that not all databases support efficient FirstResult and MaxResults implementations. But even those that don't have built-in support for skipping n rows, the usual use case is to skip where n is small. The most frequent case is FirstResult == 0 followed in rapidly descending order n, 2*n, 3*n, and vanishingly small. And most databases will be reasonably efficient for these common cases. Craig On Dec 11, 2006, at 5:35 PM, roger.keays wrote: Hi Patrick, Thanks for your detailed reply. Patrick Linskey wrote: If what you're looking for is to hold the cursor to the DB open across multiple requests, you'll need to create an extended-persistence- context EM (either via a stateful session bean or via using a non-JTA entity manager, obtained through an EMF), and then do the query in that EM and bind the query into session state somewhere. Of course, all the normal cautions about keeping database connections open across multiple requests apply. I guess that was the obvious solution. I subscribed to the one-pm-per-request pattern so long ago that I've even forgotten why. This works very well for me. I can bind my list to jsf dataTable and scroll through the results as they're loaded from the database. I think you just improved my quality of life :) If you're just looking to page through results for a search-result- style listing, you might be interested in the JPA Query.setFirstResult() and Query.setMaxResults() calls -- these allow for efficient (but non-isolated) paging through queries. Don't forget to add an ordering to your query when you do this, of course. Oh, and OpenJPA is smart about using range data in the query cache. I tried this out also and it seems to be quite efficient (not all orm products are as good). Not as convenient as the LRS, but good to know that OpenJPA is smart about ranges. Cheers, Roger -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED] Sent: Saturday, December 09, 2006 9:24 AM To: open-jpa-dev@incubator.apache.org Subject: Re: extending the life of a LRS query I am by no means an OpenJPA expert, but I did see something related to this when reading the docs yesterday. OpenJPA has a QueryResultsCache where it keeps the results of a query so if you run the query again you get the same results (I'm not sure if that is what you want). Here is the code from the docs: OpenJPAEntityManagerFactory oemf = OpenJPAPersistence.cast(emf); QueryResultCache qcache = oemf.getQueryResultCache(); EntityManager em = emf.createEntityManager(); Query pinQuery = em.createQuery(...). setParameter(0, paramVal0). setParameter(1, paramVal1); qcache.pin(pinQuery); Query unpinQuery = em.createQuery(...). setParameter(0, paramVal0). setParameter(1, paramVal1); qcache.unpin(unpinQuery); Hope that helped. -dain On Dec 8, 2006, at 8:04 PM, roger.keays wrote: Hi, I'm trying to use OpenJPA's fetch plan extensions to have a query return a large result set. It seems to work okay, except that the LRS gets closed / detached with the EntityManager, which only makes it useful for one request. Is it possible to have the LRS stay open after the em has been disposed? Thanks, Roger -- View this message in context: http://www.nabble.com/extending-the- life-of-a-LRS-query-tf2784490.html#a7769269 Sent from the open-jpa-dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/extending-the- life-of-a-LRS-query-tf2784490.html#a7825755 Sent from the open-jpa-dev mailing list archive at Nabble.com. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
RE: Get primary key from persistent bean
On Dec 11, 2006, at 6:03 PM, Craig L Russell wrote: Hi Dain, I've never seen an @Entity without an @Id annotation. I don't believe it is a valid JPA mapping without an @Id. That said, it's not required to be named Id. I'm not using annotations at all. Everything is done in the mappings xml. All entities must have declared identity, but they can use compound identity. BTW another thing that JPA needs is an equivalent of the OpenJPA LifecycleListener. The interceptor stuff doesn't cut it since beans can override the interception and it is just a PIA to get your interceptor added to ever bean. You might be interested in the org.apache.openjpa.event.TransactionListener stuff. Also, note that OpenJPA allows re-entrancy and full mutability in callbacks and listeners. -Patrick ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Get primary key from persistent bean
Dain Sundstrom wrote: This is a major hole in the JPA spec if you ask me. +1 ! I don't use @Id either -- View this message in context: http://www.nabble.com/Get-primary-key-from-persistent-bean-tf2796004.html#a7827429 Sent from the open-jpa-dev mailing list archive at Nabble.com.
Map based one-to-many
You new it was coming... so do Map based collections work? :) As many of you know, I'm trying to implement CMP2 on top of OpenJPA. To implement CMR collection sets, it would be very convenient to have a MapPK, Bean instead of just a SetBean, so I was very pleased to see support for this in the JPA spec. Unfortunately, when I have Map one-to-many field with a with a map- key, OpenJPA starts generating SQL for which include a join table. I would have assumed that a SetBean and a MapPK, Bean would generate the same sql with the only difference being that the latter would result in map.put(pk, bean). Is my assumption wrong? Is my mapping wrong? (sorry about the lack of a readable data model) entity name=OneToManyA class=org.apache.openejb.test.entity.cmr.onetomany.ABean_JPA table name=OneToManyA/ attributes id name=field1 column name=A1/ /id basic name=field2 column name=A2/ /basic one-to-many name=b map-key name=field1/ /one-to-many /attributes /entity entity name=OneToManyB class=org.apache.openejb.test.entity.cmr.onetomany.BBean_JPA table name=OneToManyB/ attributes id name=field1 column name=B1/ /id basic name=field2 column name=B2/ /basic many-to-one name=a join-column name=FKA1/ cascade cascade-all/ /cascade /many-to-one /attributes /entity Thanks, -dain
