: For posterity, I think we're going to remove 'preference' data from Solr : indexing and go in the custom Function Query direction with a key-value : store.
that would be my suggestion. Assuming you really are modeling candy & users, my guess is the number if distinct candies you have is "very large" and hte number of distinct users you have is "very large" but the number of prefrences per user is "small to medium" you can probably go very far by just storying your $user->[candy,weight] prefrence data in the key+val store of your choice, and then whenever a $user does a $search, augment the $search with the boost params based on the $user->[candy,weight] prefs. if you find that you have too many prefs from some users, put a cap on the number of prefrences you let influence the query (ie: only the top N weights, or only the N most confident weights, or N most recent prefs) or aggregate some prefs into category/manufactorur prefs instead of specific $candies, etc... Having said all that: with the new Solr NRT stuff and the /get handler real time gets, you can treat another solr core/server as your key+val store if you want -- but using straight SolrJoin won't let you take advantage of the weight boostings. -Hoss
