This question is re: HSEARCH-566: Support mapping of @javax.persistence.ElementCollection
http://opensource.atlassian.com/project ... SEARCH-566

The issue is marked as targetted for 3.3, but is still in status Unresolved and the comments sound like the feature is not in for 3.3..

I've looked at the pdf docs for 3.3RC1 but see no mention of ElementCollection. Before I spend time building a test project and experimenting, can I ask if this feature is supported?

I guess it would mean we could define a collection in java code, and have each member of the collection appear in the index, i.e.:



Also, will we be able to map a collection of diverse types like:



where each value of attributes is a different type? (Integer, Date, String etc.) or is the best way to model attributes of diverse types to express them as distinct fields with their own @Field annotation and mapping (bridge etc.)?

Some background to my question: I have a basic Item class which is mapped to a lucene index using HSearch 3.2. A customer wants to be able to store a custom type of item (motorbikes), which will need custom fields being mapped and searchable (cc, year, registration number). A perfect solution would be to be able to store a Map<String, Object> of e.g. "cc" => Integer(1000), "year"=>Integer(2002), "regno"=>String("ABC123") .. but I imagine this will be impossible to map to a Lucene index via a simple @ElementCollection annotation, right?

I guess the 'best' way handle these fields is to derive a class from my Item class and add these fields as a specific attributes annotated with @Field.

A test has shown me that simply deriving a Bike class from Item, and adding these fields, makes the new fields show up in the database 'item' table, and on the Item lucene index, so this solution would seem to work, but I'd rather not express the fields as distinct attributes if I can avoid it, because my data model becomes hardcoded in my java source, rather than being left as a very flexible Map<String, Object>.

Comments on any of these points would be welcome :)
Thanks
Nick

The short answer is HSEARCH-566 is not yet implemented.
I am also not so sure how much your usecase has to do with @ElementCollection. Just because you are using an element collection does not mean we can automatically know how you want to index your map. That said, you can always write your own field bridge in which you index your Map<String, Object> any way you like. Have you considered this approach?

--Hardy

Thank you for your comments.

In my naivety, I presume that introspection of the contents of the Map at the time of serialisation to the index would give enough info for basic indexing. I imagine this is the direction that HSEARCH-566 is heading in, though perhaps it's strictly type-safe and actually the types of the object bridged to the index are fixed at compile time.



I had not thought of that. I've knocked together a FieldBridge implementation that looks like it should do the job.

I annotate my Map like this:



And the MapFieldBridge.java looks like:



This seems to be populating the index correctly. I'll go see if it plays well with my search and rehydration code. I have a feeling I need a TwoWayFieldBridge, not just a FieldBridge, in which case, how would it know what object type to turn each String from the lucene index back into? Perhaps I would have to store a metainfo field per Map field for this purpose.

Sure, you can add whatever information you need into the index.

I mistakenly defined my Java attribute as Map<String, String> earlier, which led me to believe my code was working. What I actually needed was:



The use of "String, Object" as Map template arguments is giving me:



I think this job is beyond me, I'm just going to have to keep it simple and derive a class for my custom attribute, index them using simple built in bridges, and write a bunch of special handling code for my custom entity objects. (and then possibly have to unpick all this work if HSEARCH-566 means I can do all this in the way I first envisaged :))