Hello,

Working on our project, which uses Hibernate for O/R mapping, I came across the following idea :

Context : Almost any real-life application has objects that represents enumerations, things like statusses, currencies, languages, etc.. ( == *low* number of objects that never change on-line)

Currently hibernate can support this in one of two ways : PersistentEnums, or as a fully mapped object, that exists in the database.

The former obviously allows for very high efficiency, because almost zero-cost (no I/O at least) is associated with it. It does have it's drawbacks as well.

- If you want to create extra values in the enumeration, you need to change the class itself.

- Reporting tools, that are outside of the project itself (as is the case in our application, reports are generated with cognos Impromptu web reports), cannot get to properties of the enum (e.g. if you like to have a report with a description of a status field you need some other solution)

- You cannot enumerate the Enum (!). eg. HQL = 'from package.EnumType' does not work.

The latter, creating the enumerations as tables in the DB, and then mapping them has advantages/drawbacks as well :

+ You can enumerate them in HQL ('from package.Class'). You often want to do this in a business facade, because the user interface presents the user with a list of possible values.

- Performance is lower, because of joining.

Currently we are solving the reporting issue by shadowing our PersistentEnum values as a table as well, which is joinable in the reporting tool. This still has the performance advantages for the java side of things, but allows the reporting to work ok. This of-course requires us to sync the PersistenEnum with it's shadow table.

Now for the idea :

If we were to create small tables for all of our enumerations, and map them with the standard hibernate mapping, and mark them immutable :

+ It would be possible to simply cache these objects in ram (because we never insert/delete or update these objects).

+ We would still have the advantage that we can now enumerate them in a query (not possible with PersistentEnums right now)

+ Off-line changes to the database would be reflect in the objects (restart of application, of-course). (No need to sync PersistentEnum and it's shadow-table)

Hibernate could automatically detect this case by checking all immutable classes, and performing a SELECT COUNT(*) on the corresponding table, and if the count is lower then a (perhaps per class overridable) treshhold, simply create and populate all corresponding objects at application start-up.

What are your thoughts on this ?

Kind regards,

Dimitry.

You forgot a third option. Using UserTypes. This is how I handle enum/cannonical data in my apps with Hibernate.

What it sounds like you are attempting to deal with is reference data, not cannonical data. Reference data is normally modelled as an entity in Hibernate. And sure you could cache these.


I just don't see this functionality as best handled within Hibernate itself. This is application logic, not domain/mapping logic.

I'm using a domain model approach (which basically means I use POJOs that know nothing about persistence) an and handling persistence with hibernate. I came across the same problem and decided to create static enumarations built into the doamain model (i.e a Rate object will have a static Currency enumeration).

I am aware and agree with you in the dissadvantages this approach has, BUT the main reason I didnt want to use hibernate PersistentEnums
is that persistence detail will start creeping their way to the domain layer.

If you someday need to stop using hibernate (although in my experience hasnt been the case) and change your persistence mechanism (i.e: beguin to use JDO) then you will have to make changes to your domain model.

As for reports, we are using Jasper Reports, which could enable us to generate reports using POJOs but we want to talk directly to the DB for performance reasons so we also have the enumarations in the tables and just use joins.

Oh.. if you insert data only through your java app, you could gain a little performance in the DB side by removing any insert referential constraints.





It would be nice to have a feature like this in hibernate... , instead of declaring a property as a persistenenum, declare an entity, load changes on startup and cache it!