On Thu, Dec 11, 2008 at 4:41 AM, Chris Hostetter <[EMAIL PROTECTED]> wrote: > > : 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?); yes TemplateTransformer can help you here
approach #2 would probably be possible using multiple root > entities (assuming multiple root entites means what i think it means) Yes ,multiple rooot entities can do the trick (with a separate doctype). > > : 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 > > -- --Noble Paul
