Comments on: JPA implementation patterns: Mapping inheritance hierarchies

By: Vincent Partington

Vincent Partington — Fri, 18 Sep 2009 10:10:35 +0000

@Simon Massey: Using the @Pre/@Post handlers is an even neater way to solve this than doing it in the getters/setters as I propose. Basically, you actually implemented the “Clever use of the @PrePersist and @PreUpdate lifecycle hooks” I mention.

By: Simon Massey

Simon Massey — Thu, 17 Sep 2009 23:56:44 +0000

We use the “clob/blob overflow column” pattern extensively in some framework code. In our case it is an XML serialization of the subclass fields. The proprietary framework in question is a few years old now so it is hibernate not jpa with interceptors not @pre/@Post hooks but doing exactly the same thing.

The framework allows for tens of thousands of custom types going into the same smallish set of entity tables. Our business users design new types on the fly from within the application and we use a custom class load to generate all the pojo classes at runtime on first use. So it has mega wide and mega deep hierarchies all generated at runtime.

The generated subclass types have unmapped properties fields with setters and getters. Within hibernate interceptor life cycle hooks we pack those unmapped subclass fields into the mapped xml base class blob to dehydrate the object to store it, then on rehydration unpack them from the xml to activate it. Once again you could do that with @pre/@post handlers.

It has been a few years since the first version of our framework. Your suggestion here on this blog is the first time I have head of anyone else doing the same thing.

By: Vincent Partington

Vincent Partington — Mon, 22 Jun 2009 07:27:57 +0000

@Andrew, @Maarten: As Maarten already guessed I perform the serialization/deserialization in the entity class to have more control over it. This way I can use different serialization mechanisms, set the blob field to be updatable, catch and handle ClassNotFoundExceptions and other serialization errors. Using a Hibernate UserType would have been nicer but does not work for all JPA providers. The interesting thing with this and with other JPA implementation patterns (bidirectional associations, using @PreRemove, bidirectional associations vs. lazy loading, using UUIDs as primary keys) is that they all "pollute" the entity class with their "special JPA sauce". It would be nice if one could define an external "persistence handler" that takes care of all this nasty stuff. Something like a UserType but with more abilities. Instead of the @Pre/@Post lifecycle hooks with only invite you to do this kind of nasty stuff. I guess this matches nicely with my comment at the beginning of the series that the JPA abstraction, as it is today, is pretty leaky.

By: Maarten Winkels

Maarten Winkels — Mon, 22 Jun 2009 02:00:23 +0000

@Andrew: The default for JPA is to store a complex, non-entity property in a BLOB. It uses standard Java Serialization of course. Due to its limitations Vincent mentions in the blog, the serialization/deserialization is performed in the Entity class, I suppose.

+1 for using a UserType for this kind of transformation. But I think UserTypes are Hibernate specific and not JPA-ish.

By: Andrew Phillips

Andrew Phillips — Sun, 21 Jun 2009 20:23:59 +0000

Is it desirable to have to the serializedCommand byte array as a member of your entity class? The transient command object would appear to be the one that is the “natural” member of your domain model – the fact that it happens to be persisted as a byte array is purely an implementation detail, and probably not something you would want to leak into your API in this way.

Would a Hibernate user type not be more appropriate in this case – I think there might even be a “Serializable2LobUserType” out there already.