I am converting an old application over to hibernate.

Users are allowed to create attributes. When I enter an attribute I do something like this:

ID sort_order value
1 1 name
2 2 address
3 3 phone
etc.

Anyway, my ID, is a PK, and hibernate does the increment. The sort, I have been getting the max(sort_order) value plus 1.

All works well, except now I need the ability to change the sort_order within a interface for the user. So the usr can say address needs to come before name. I do not want to change ID, so I need to change the address sort_order to 1 and then change the name sort_order to 2.

Also, if a attribute is deleted, I need to adjust the rest of the sort_orders. I used to do a query like so:

query = "update table set sort_order = (sort_order - 1) where sort_order > ?";

How, or what is the best approach to handle this within hibernate? Do I just do a query like above, or play with a list or set iin hibernate?

Any input would be appreciated.

Sincerely
Scott

Map this as a list, with sort_order being the index. Hibernate will look after the rest.

Thanks,

But if I map the attributes as a list, and add an index for the sort_order, do I just get all of them in a list, then shuffle, delete, move them in the list, then do a saveUpdate()? on the List of data?

Not sure how I can achieve this. These lists are owned by an entity, also, and these attributes have an entity of course, but have a foreign key in the attribute table. So I guess, I could grab the parent, which gets the list of attributes then shuffle the attributes and then do a saveUpdate() on the primary key entity?

Let me know if this makes sense and would work or not.

Thanks,



group
ID PK
name
sort_order


attribute
ID PK
group_id FK (to grioup)
sort_order
name

attribute has a many to one to group.
or
group has a one to many with attribute

Lists, and all collections, are always owned by an entity. Hibernate does not support the concept of a "top-level" list of entities, except as the result of a query.

If you remove an item from the list and put it back in somewhere else, the indexes are updated correctly. If you map the index as a read-only property (as I frequently do) then you have to remember that the property is only an indicator, and the object's position in the list is the real index.

I don't think that I've ever tried saving a list item except via a cascade from the list-owning entity, but I believe that it will do what you'd expect. If you load a list item by id, modify it and save it, its sort_order won't change: you have to save the list-owning entity to modify list indexes. You should test that assumption though.