HIbernators,

On a generic level -

I am curious how I can save default values to a database. I want there to be an AppDefaults class that contains a map of key/value pairs. I also want the AppDefaults to be a singleton. Further, the key/values must support CRUD.

This is extremely straight forward in OO. However, when I map this to a database it is awkard. If I map the AppDefaults as a class containing a map of values there is one table that contains a single column and a single row that exists only as a placeholder for an instance of AppDefaults. Then, there is another table that represents that map itself with references back to that single instance of AppDefaults.


So, what are my options to map this in such a way that I can still have the benefits of transitive persistence and not have a table that contains just a single column and row?


Thank you for any help in this discussion - as always, Hibernate is an excellent tool.

If you use a real object model, you'll be able to do this mapping. Try to model the properties as objects and use several tables. Or, if these application defaults don't need to be changed at runtime, I suggest you create a very quick XML file (using digester or such thing) or a basic properties file (which is also a Map) and load them into the application when it starts. Try and use the simplest way for the job. Only store this stuff in the DB if you actually need to change this stuff at runtime. Usually configuration is good enough.

Agreed - IF the values didnt need to change at runtime, then I'd be taking a different approach.

But, they do.


I can VERY easily map this as a parent (AppDefaults) that contains a map of default values. HOWEVER, the problem (I think it's a problem because most dba folks would not like this) is that I will have only one instance of AppDefaults and as such I'd have a table in my database that ends up with a single column and a single row which is the ID of the persitent instance of AppDefaults. Do you see why this seems bad ?

So, what I am looking for is a way to manage a bunch of key/value pairs in an efficient manner that takes advantage of Hibernate's inherent greatness.


Thanks

Just make an ApplicationProperty object that corresponds to an application_property table. You can make a singleton (in however manner you prefer using Spring or a real singleton) called an ApplicationPropertyManager that contains a map of ApplicationProperty objects. Make the id of the property the key to the Map and the value the ApplicationProperty object itself. The ApplicationProperty might be simple in that it may only contain value, but it might contain other metadata for the ApplicationProperty too. This is the simplest approach I can think of and I'd do this myself until the configuration requirements became more complex.

Let me know if I'm understanding the problem correctly. Hope that helps.

Regards,
Ken Egervari

Just to really bring home the point....


I think I'm running into a limitation of ORM. Consider ANY object that is simply a parent for a collection of values. When mapped, you end up with two tables. One table stores an instance of the parent that turns out to simply be a single column (the Primary Key). The other table actually stores the data of the collection with references back the Primary Key of of the parent.

Now, consider we have several instances of this type of object. The database then has a table that LITERALLY only has one column and that is the Primary Key column. I can't imagine DBAs would find this appropriate.

However, we ( OO people ) need those because we need a way to represent an instance of an object in our system. So, in the case of a "persistent singleton that holds ONLY a collection of value types" we end up with a table in our database that is simply a holder of a single primary key and nothing else.



It all seems pretty clear to me that what I'd like to be able to do is simply not possible via ORM. I'll simply have to choose either an OO-Centric approach, or a Relation-centric Approach.

LASTLY - I am definitely not the first person to reach this connection on how to handle the case I've described so I'd like to hear others opinions on this.


Thanks

Ken,

I appreciate your response(s). The more recent one is on par with what I've been planning on.

I'd be interested to hear your comments on my last post. I think it clears up the 'problem' on a more general level.

Thanks

Well, since the singleton is one object per application, and the database is for a single application, then you can really get away without storing the id for the singleton at all. The ApplicationPropertyManager is really just a DAO facade to your Hibernate queries so you can look up all all the properties in the system or directly by their name, or however you would like to query them.

If you need to have system properties for multiple application groups, then you can do can either add an ApplicationGroup object (and table), or you can simply make ApplicationProperty have a parent() that points to another ApplicationProperty (and this table closes on itself rather than pointing to a second table). Closure is a good design.

There are lots of ways to do this really. Hope that helps and ask if you have any more questions.

Regards,
Ken Egervari

Oooh, now we're cookin.

Your remarks on consider the AppDefaultsManager as a DAO is a quite nice one. While Im not sure if it's a good approach for the ORM - singleton notion in general it does seem to benefit my issuse with AppDefaults.


I'll have to think on your latest comments over night.


Thanks much

I just wanted to follow up for the benefit of anyone curious


After much deliberation I've decided that it's not necessary to really have an AppDefaults 'domain model' object. What I really want is for some database to hold keys and values that will be used for default values in my application. I was quite frustrated that I couldnt come up with a Hibernate solution that was clean and made sense.

I then realized that this wasnt a job for Hibernate and it was like fitting a square peg into a round hole. The problem isnt a problem. Hibernate is an ORM solution. What I wanted to do wasnt an ORM problem. So, naturally I couldnt see a nice solution through hibernate.

I've ended up going with a recommendation similar to my fellow post-ers. I have an AppDefaultsDao that persists a map of values via JDBC. It is probably the most straigtforward case for JDBC.

Anyway, I just wanted to put this here so people dont spend as much time as I have on this. I've spent so much time the last couple of months learning about Hibernate and ORM in general that I see everything through and ORM lens. Well, not all problems require an ORM solution - I know realize this.

MORAL OF THE STORY: NOT ALL problems are OBJECT/RELATION Mapping Problems.

Hibernate is awesome.

Joe