Here's another option that might suit everyone:
- We change the enhancement so that a non-default auto-assigned pk field
makes an instance detached even in the absence of detached state, as I
proposed.
- If the entity doesn't use auto-assigned pk fields (and has no version
field) and detached state is in use but not present,
PersistenceCapable.pcIsDetached will now return null for JPA enhanced
entities. We already treat null as "I don't know", and it causes us to
go to the DB to see if there is an existing record. For JDO enhanced
entities, we'll return false as before. We can do this by returning the
result of a new private pcIsDetachedStateDefinitive method we'll add,
and the JDO enhancer will change the return value of this method from
null to false. This won't cause any compat problems with
already-enhanced entities, because it won't be part of the public
PersistenceCapable interface.
This way the corner case you're concerned about is covered without
having to change the default config, and meanwhile JDO users still get
efficient persist behavior.
The downsides are:
- Merging new version-less and auto-assigned-pk-less entities (i.e. ones
you really do want inserted, not updated, but are found during merge
instead of passed to persist) still causes a DB lookup to make sure
there is no existing entity with the same PKs. I think this is so
infrequent as to be perfectly OK.
- If a user upgrades Kodo without reenhancing OPENJPA-245 won't be
"fixed" for him. Then when he reenhances the behavior will change and
it will act fixed. Kind of odd, but I can live with it.
On Fri, 2008-04-04 at 14:26 -0500, Michael Dick wrote:
> Hi Abe,
>
> I'm guilty of not updating 245 after I finished it. The scenario that got me
> to look into it is the edge case you mentioned - the entity has no auto
> generated fields.
>
> Improving the story for other scenarios sounds good to me and I like the
> approach.
>
> My main concern is that we don't break the edge case I mentioned. Something
> like this should still work :
>
> class Person {
> @Id
> int id;
>
> String name;
>
> // setters etc.
> }
>
> Person p = new Person();
> p.setId(1);
> p.setName("Mike");
> em.persist(p);
> // commit tran
>
> // later
> p = new Person(); // new entity - matches an existing row.
> p2.setId(1);
> p.setName("NotMike");
> em.merge(p);
> // commit tran
>
> Under proposal #1 I'd have to add something like this to persistence.xml
> <property name="openjpa.DetachState"
> value="fetch-groups(DetachedStateField=false)"/>
>
> With proposal #2 I wouldn't have to do anything, but it improves performance
> for a smaller set of users.
>
> I'm in favor of the first approach. Many users who want this kind of
> processing will set the openjpaDetachState property to change loaded to
> fetch-groups or all (otherwise you lose the ability to set a field to null).
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.
