Hi folks,

I have an interesting situation I hope someone can help with.

I've read all about UserTypes and CompositeUserTypes, and I've looked at the DoubleStringType and MultiplicityType examples numerous times, but a solution still eludes me...

I'm trying to create a wrapper class that knows how to persist instances of special java.security.Permission subclasses to a table. Lets say the root level class of these "special" subclasses is called PersistablePermission. PersistablePermission and all of its subclasses have 3 fields:

id - a UUID object
name - a String
actions - a String (comma delimited)

The UUID object is used by all of my persistent objects and is used as the primary key for all of my tables. I already have a UserType for it, and everything works nicely in Hibernate for my other classes.

I have one table that stores all permission instances under this subclass hierarchy. This is a good thing because, as far as persistence is concerned, they all only need to store the above 3 fields. In order to determine which class to instantiate when I pull a record from the database, I have a fourth column called "class_name" which stores the fully qualified class name of the PersistablePermission subclass.

Now, my dilemma with the UserType is that I only understand how to use it for a particular property in a class which may correspond to 1 or more columns.

I don't want to persist a property, but rather the whole instance.

What I want is more of a wrapper where I could do the following:



Upon executing this code block, a new UUID should be created by Hibernate using my UUID UserType class and set on the customPerm instance (using the setId(UUID id) method). Then a row in the permissions table is created, with the four columns populated (permission_id, name, actions, class_name).

I'm pretty sure Hibernate can do this, but how to make a wrapper class eludes me.

Can anyone provide some insight?

Thanks very much,

Les

For the benefit of anyone having the same problem:

A seperate persister class is not needed.

The <subclass> element in the hbm mapping file will do the job. <subclass> relates to a "table-per-class-hierarchy" mapping strategy, not a "table-per-concrete-subclass" strategy.

This way, only one table is created for the parent class and all of its subclasses, and each subclass instance is persisted to a row in this table.

This means that the table will have columns for all attributes for all of the subclasses. The <discriminator> element tells hibernate which subclass to instantiate upon pulling the infromation from the row.

Because this approach contradicts good RDBMS design principles (i.e. data normalization is not maintained), i generally loathe a table-per-class-hierarchy strategy. However, for java.security.Permission and all of its subclasses, this is usually a good fit.

The reason is because most custom subclasses of java.security.Permission do not have any extra attributes other than the already defined "name" and "actions" String attributes. However, the implies() logic almost always changes per subclass. Since an O/R mapping strategy persists attributes and data (not logic), a single table is a good choice for this special type of class hierarchy. The only thing needed is an extra discriminator column to distinguish instance types (e.g. the fully qualified class name of the subclass is common) .

If any of my custom Permission classes did require additional attributes, I might rethink this strategy and perhaps use a <joined-subclass> approach to maintain data normalization.

Les