I'm trying to map rows in a table as instances of a Java enum. Each row will be uniquely identified by a name column (values of which will be the names of the defined enum instances). Each enum will need to load a couple of other fields (including an ID, for use in associations) from the database.

I've read all the tutorials I can find on enum mapping, but they all seem to relate to using enums for values within the column of a table - i.e. using enums for values, rather than entities.

One of the biggest challenges I can see with this is at what point to load the fields from the database - the instances will be created when the enum class is loaded, but will have no session with which to query the database. It's acceptable for me to use a specialised DAO which can be given an instance of the enum and which will then load the fields.

Has anyone tried to do a similar thing? Does anyone have any tips on how to proceed?

Enums are constants: values, not entities. They do not have variable bits. If you need to load values from the database, then they're entities, as you correctly point out. Therefore, they're not enums, and should not be mapped as such. That's why you haven't been able to find any examples on this sort of thing.

pdm9

I did what you are talking about in my last application. I setup the entity CATEGORY as read-only immutable data, and then setup the Query Cache to store a simple Query "from CATEGORY". The objects are cached and ready to be used...(you can rerun the Query at no cost in a page-startup routine, since it is cached)

For Java Enum... I had to hard-code the Enum class with the same values (not ID's) that were stored in the database (this could be a generated class, of course to make it more consistent with the database).

On save, when I assigned a value from the Enum I had to translate it into a hibernate object and then save the parent class.

On query of parent (ie, my Event class), you should setup your <many-to-one tag to have the attribute fetch="select" - this way it won't join the data on selecting from the database, but rather fetch it out of cache. (make sure to set it up a cacheable data, else you'll get the N+1 select problem).

Ok - I can agree with this up to a point, but the situation was that I had a fixed number of known entities and just wanted some of those entities' fields to be loaded from the database (and not hard-coded). To me this is still a perfectly valid use for an enum.

Regardless, the requirements have changed slightly to mean that my entities must now 'extend' from another table, which is mapped as a separate persistent object. Enums can't have any inheritence relationships, so I'm going to need another approach anyway (for the record, I'm planning to write a plain object for the entity and then declare the known instances as static fields within this class, but stipulate that all calling classes must pass these objects to a DAO before use to get back a version that is attached to the current session).

Thanks to both for your help.

I guess we'll have to disagree on this point then. I'll take comfort in knowing that the java core development team are with me on this one though: they use the phrases "enumerated type" and "enum constant" interchangably. I hope that doesn't leave any room for misconstruing their intentions. If you want to enumerate almost-constant values, then you can use a normal class and give it enumeration-like properties (e.g. make the constructors private, forbid API users from using mutators, etc.). But if you're going to use the enum keyword, thus allowing you to use identity equals, values as switch constants, etc., then the enumerated type must provide only enum constants.


They can in java5. They can extend other enums, or implement any interface.

For the record, this is incorrect - they may implement interfaces, but they may not extend other enums. They may have instance specific class bodies (providing polymorphism), but not the explicit extension of one enum by another that you mention.

Check out this for Enum

http://www.hibernate.org/272.html

I hope this helps!