| soft deletes and implications [message #518157] |
Wed, 03 March 2010 10:10  |
 Ari Meyer
Messages: 136
Registered: July 2009 |
Senior Member |
|
|
Hi,
I'm working for a client that mandates basic auditing and the use of
soft (virtual) deletes, wherein we simply write to the
DELETE_DATE/DELETE_USER fields on a record to denote deletion. I am
using an EntityListener with @PrePersist/@PreUpdate methods to implement
basic auditing/soft delete behavior. This has worked fine for a long
time now.
Now we're starting to implement soft delete behavior more completely.
Up to this point, we really didn't implement it correctly, but as we
approach a rollout, we have to finish this. Soft deletes cause all
kinds of issues. First, JPA mapped relationships (@OneToMany,
@ManyToMany, etc) don't function properly, since the basic retrieval
mechanism just brings back all the records satisfying the relationship.
I don't know of any way to restrict the retrieval to only bring back
records "WHERE delete_date IS NULL" -- is this possible? Assuming it's
not, we have to manually filter out any deleted records before returning
from the getter method. Only other way I know is to write JPQL, which
is obviously not desirable when simply navigating an object graph.
Similarly, I don't know of a way in the JPA mappings to specify
cascading soft deletes. We are now traversing the object graph somewhat
manually to set the DELETE_* fields. I'm guessing I could use the
EntityListener to listen for updates and somehow cascade the DELETE_*
field marking down the hierarchy, but I'd definitely prefer to specify
this behavior via annotations, if at all possible. At least our current
solution works for this and is not too messy.
Lastly, and most painfully, if a record with a particular natural key is
soft-deleted, and later someone tries to insert one having the same
natural key, you'll get a constraint violation. So you have to see if
the "new" record matches a soft-deleted one based on natural key, and
then simply null out the DELETE_* fields of the existing record and
update it. Certainly equals()/hashCode() implementations based on
natural key help here, but it's still ugly.
Is there something in standard JPA or Eclipselink extensions that can
help with soft deletes? I've only looked briefly at standard JPA
options thus far for an answer, but Eclipselink-specific code is
definitely welcome. At least what we currently have works, but I'm
hoping to find a cleaner solution. I have to think that many other JPA
users are doing soft deletes, but I haven't seen much from searching the
web. I did find this with Hibernate extensions:
http://opensource.atlassian.com/projects/hibernate/browse/HH H-4286 --
does Eclipselink offer something similar?
Thanks!
Ari
|
|
|
| Re: soft deletes and implications [message #518592 is a reply to message #518157] |
Thu, 04 March 2010 15:08  |
|
EclipseLink has several features to support soft deletes.
If you are also looking for full history support, you could use EclipseLink's history support, which will give you automatic soft deletes and full historization.
For just soft deletes, there is an additionalJoinExpression on the DescriptorQueryManager, you can use a DescriptorCustomizer to set this to automatically filter deleted objects from all queries.
You can also over the deleteQuery or deleteSQLString on DescriptorQueryManager to perform an update instead of the delete. Then you can just use regular remove() and cascades.
James : Wiki : Book : Blog : Twitter
|
|
|
|
Powered by
FUDForum. Page generated in 0.02888 seconds
] 
Search
Help
Register
Login
Home
