I know why Hibernate doesnt do this, and I respect how Hibernate does everything by the book (e.g. arrays have an ordering, and a normal one-to-many doesnt, also arrays allow multiple references to the same element and sets and normal DB relationships do not), however, sometimes a product can be flexible to help integrate with the most situations.

We have a framework that needs things in an array to display on the screen. But we also have legacy data where we do not have an index column (and it is inconvenient to add one). OJB does this just fine, have an array that maps to a one-to-many with no index column, but we would like to use Hibernate.

Anyways, I think it would be useful if you added this to Hibernate.

1. If there are multiple references to the same object, just keep one of them (one of the costs of doing business in a relational DB... in our framework that would never happen but I could see how you could think it might be a problem)
2. Select them in an arbitrary order, or let the user use an order by
3. When updating, just use the primary key and not need the index column

I think the only thing we can do (after unsuccessfully trying some complex Java workarounds) is to add the index column, and have a DB trigger that fixes this column when other apps insert/update/delete. But it would be nice if we didnt have to do this.

Anyways, we are having a good experience with Hibernate, thanks for the good work!

Chris

You can also just map a private get/set Method that returns your array as set.

I tried this but I thought Hibernate didnt like my returning a different Set object than the one it set in the first place.

i.e.

1. Hibernate sets its CglibSet
2. I go through that, and convert it into my own datastructure in the setter
3. When hibernate gets the Set, it gets a HashSet

When it committed it tried to delete all associations, and I assumed it was because the dirty checking wanted it to have the Set object that was set by Hibernate. Is something else amiss?

In any case, this is exactly what I think would be useful for Hibernate to do. The approach we are discussing also makes the Javabeans hairier since there will be the same data acceible by properties with different names, and other things like serialization to XML that uses Javabean properties might get confused or duplicate data...

Chris

Well, store the old set somewhere, and change its state when get is called - Hibernate will surely not be changed to accomodate such things, it just respects the array and collection contracts.

OK, sounds good. Thanks for the answer. Just a quick followup (probably last message), I understand what the collection contracts are, the interfaces where each method is described. But what is an array contract and how would the method described above violate it? If you do not guarantee order when selecting a set, I dont think it violates anything designed in Java, it just gives the integrators more flexibility... e.g. if you do two selects ain a row and the array is in a different order, this is expected if there is no index column or no order by, that is how selects work. I would think. Thanks! Chris

Its more that an array (just like a List) by definition has an order, a sequence. In an array, that sequence is based on the elements position within the array.

I understand your wanting to be ad hoc about this, but the fact is that Hibernate cannot have the benefit of this ad hoc nature. What goes out must come back in.

If you don't agree with this, or feel strongly about it, I'm sure we would consider a patch that implemented this for arrays while leaving the default behaviour as-is.

Exactly. In a List, you need a heuristic for seeing how two elements are ordered since if you add a new element the list needs to figure out where it goes. For arrays, that is not the case. One point of an array is the program decides the unique ordering from the outside, not by inspecting each object.

I like how Hibernate is pure about everything, but there is a serious disconnect here. In relational databases, the default 1-to-many relationship is not ordered. e.g. a Person has many affiliations, but these are in no particular order. So for legacy data this is needed. On the web side, some frameworks need an order. e.g. the when the textfield in the 3rd row is edited, it needs to save back to the 3rd affiliation. Therefore there is ordering. So for legacy frameworks, arrays should be supported. When these go back in the DB, just take the array, and use the primary key for each object, and update them (or disassociate them if they arent in the array anymore)



I think it would help out a large array of new developers so they can be all set with Hibernate. If no one is interested in the coding, I could take this on as a long-term project... (busy at the moment, but would like to give it a try eventually), though let me know if it will be accepted once written...

Thanks!
Chris

Its not at all hard to implement, y'know.

Just write an org.hibernate.collection.UnorderedArrayHolder that works exactly like org.hibernate.collection.Bag. (And an UnorderedArrayType, like BagType.) You wouldn't have to do much thinking, just copy existing code. Hibernate persistent collections framework is very extensible.

Gavin, first of all, when we get our framework integrated with Hibernate, we will purchase a support contract through JBoss, just so you know your efforts will not be uncompensated.

Im thinking what you suggest is a good idea. Im tossing around the idea of doing some sort of Map that will assign keys to each object in the collection, or an array would be nice too. Once I write this class that you suggest, how do I hook it up to the XML config file (e.g. if I configure a "set" in the hibernate config file, how do I link that with my new class).

Thanks!
Chris

org.hibernate.cfg.Binder parses the Hibernate mapping file, and creates the configuration-time metamodel, which is in the org.hibernate.mapping package. You would need to add a new class to the mapping package, and stuff to Binder to create instances of it.

The CollectionPersister is created from the mapping package, but you won't need to touch that part, I think.