Is there a better way to persist a map with the value being a set?

Question

I'm looked a lot into being able to use Hibernate to persist a map like Map<String, Set<Entity>> with little luck (especially since I want it all to be on one table).

Mapping MultiMaps with Hibernate is the thing that seems to get referenced the most, which describes in detail how to go about implementing this using a UserCollectionType.

I was wondering, since that was written over four years ago, is there any better way of doing it now?

So, for example, I would like to have on EntityA a map like Map<String, Set/List<EntityB>>.

There would be two tables: EntityA and EntityB (with EntityB having a foreign key back to EntityA).

I don't want any intermediate tables.

Answer 1

The way how its done on my current project is that we transforming beans/collections to xml using xstream:

public static String toXML(Object instance) {
    XStream xs = new XStream();
    StringWriter writer = new StringWriter();
    xs.marshal(instance, new CompactWriter(writer));
    return writer.toString();
}

and then using Lob type in hibernate for persisting :

@Lob
@Column(nullable = false)
private String data;

I found this approach very generic and you could effectively implement flexible key/value storage with it. You you don't like XML format then Xstream framework has inbuilt driver for transforming objects to JSON. Give it a try, its really cool.

Cheers

EDIT: Response to comment. Yes, if you want to overcome limitations of classic approach you are probably sacrifice something like indexing and/or search. You stil could implement indexing/searching/foreign/child relationships thru collections/generic entity beans by yourself - just maintain separate key/value table with property name/property value(s) for which you think search is needed.

I've seen number of database designs for products where flexible and dynamic(i.e. creation new attributes for domain objects without downtime) schema is needed and many of them use key/value tables for storing domain attributes and references from owner objects to child one. Those products cost millions of dollars (banking/telco) so I guess this design is already proven to be effective.

Sorry, that's not answer to your original question since you asked about solution without intermediate tables.