The documentation says so. However there are times where I don't have a primary key for a table (especially a database view.)

I have a few database views that join together data from several tables. The database views do not require a primary key column (or a unique column.) There is no business need for me to add one.

I have mapped a java class to the view for Hibernate. However I have not defined an "id" property because the database view does not have a primary key.

All I would like to do is have Hibernate return to me a List of my java objects when I query against the view. I don't want Hibernate to store them or compare them in the object cache (in fact I want to bypass the object cache entirely.)

If I don't specify the hibernate.id property I can't get this to work. However if I modify the database view and add a column to it that is unique, and then declare the corresponding java bean property to be an "id", then this does work.

However I'm irritated by this because the database view doesn't require the this extra column and I don't want it in there.

I've tried finding documentation or forum topics on this to no avail. Can I accomlish my task using Hibernate without modifying my view?

Thanks, Steve

Not really, as Hibernate assumes primary keys. In fact, a database is broken if it doesn't declare a primary key for a table/view. In some circumstances this might be considered "good", for example when _all_ of the columns _are_ the (composite) primary key. You might get away with a mapping like that.

I think you have hit a fundamental issue with today's SQL database products: Views, "null" and constraints. Notice that you probably can't even update your view! There is no real reason why this should not be possible.

What is worse, most database systems even allow you to update a table/view when there is no declared primary key, that means you can insert two rows with the same values! Now, this is not really anywhere close to the Set Theory of the relational model, so I leave it up to you to discover the problems that arise from this. ;)

I'd add a primary key to the view to ensure data integrity.

I'm not a database maven but I do know that it can be acceptable to define a Set of data that doesn't have 1 property on the object/tuple that declares uniqueness. But you are right in that Set Theory mandates that one identify whether some object or tuple is "equal to" or "not equal to" another object or tuple.

For my database view, there is some combination of columns that gives uniqueness. But frankly I don't want to bother writing a composite key because I'll be defining 7 columns (out of 13) that comprise uniqueness.

Practically speaking, Hibernate is great for 80% of our data access needs. However I do want a tool that given 1) a Java bean and 2) a ResultSet - it can create an instance of that Java bean and set the properties on that bean given the data in the ResultSet. Hibernate is a full-blown O/R tool that has loads of great features but I'm not sure if Hibernate can do exactly what I said above. Sometimes I don't have a primary key, sometimes I want to completely bypass the object cache (can this be done on a persister-by-persister basis???). This is a read-only view so I don't intend to insert/update into the view. I guess I could write my own CustomPersister but I read elsewhere on the forums that that is a daunting task.

BTW, I added the primary key from the driver join table and everything works fine (and the more I think about it I don't think it's a bad solution either.)

Thanks, Steve

Of course. That is what <compoisite-id> is for.



Well, it doesn't matter what the DB schema says. As long as you wrap the property mappings in a <composite-id> tag, it will work.

I simply do not see the problem here. Its trivial to do this in Hibernate.



If that is all you need, then iBATIS is a great solution.

Checkout Kodo. It is a full O/R solution like Hibernate. But it does have the feature you ask for.

posting a commercial on a 3 year old posting is funny ;)

...for completeness hibernate 3 has the feature too.