: This is really cool. Ummmm... How does it integrate with the Data Import : Handler?
my DIH knowledge is extremely limited, but i'm guessing approach #1 is trivial (there is an easy way to concat DB values to build up solr field values right?); approach #2 would probably be possible using multiple root entities (assuming multiple root entites means what i think it means) : I've taken two approaches in the past... : : 1) encode the "id" and the "label" in the field value; facet on it; require : clients to know how to decode. This works really well for simple things : where the the id=>label mappings don't ever change, and are easy to encode : (ie "01234:Chris Hostetter"). This is a horrible approach when id=>label : mappings do change with any frequency. : : 2) have a seperate type of "metadata" document, one per "thing" that you are : faceting on containing fields for id and the label (and probably a doc_type : field so you can tell it apart from your main docs) then once you've done : your main query and gotten the results back facetied on id, you can query : for those ids to get the corrisponding labels. this works realy well if the : labels ever change (just reindex the corrisponding metadata document) and : has the added bonus that you can store additional metadata in each of those : docs, and in many use cases for presenting an initial "browse" interface, : you can sometimes get away with a cheap search for all metadata docs (or all : metadata docs meeting a certain : criteria) instead of an expensive facet query across all of your main : documents. -Hoss
