My answer as usual - BlockJoin. index group as a parent document, and every membership as a child doc. In this case you somehow "denormalize" your items - every item will be indexed N times where N is a number of groups it belongs to. Potentially it can lead to duplication problem, but you haven't mention it yet.
In this case single field for sorting is enough. then you can search by ToChildQuery(GRP_NAME:foo) than gives you foo's children. BJQ-101: http://blog.mikemccandless.com/2012/01/searching-relational-content-with.html http://blog.mikemccandless.com/2012/01/tochildblockjoinquery-in-lucene.html https://issues.apache.org/jira/browse/SOLR-3076 forgot to mention there is a price for blazing speed, when you need to change membership you need to reindex whole block. On Fri, Jan 4, 2013 at 1:10 AM, Uwe Reh <r...@hebis.uni-frankfurt.de> wrote: > Hi, > > I'm looking for a tricky solution of a common problem. I have to handle a > lot of items and each could be member of several groups. > - "OK, just add a field called 'member_of'" > > No that's not enough, because each group is sorted and each member has a > sortstring for this group. > - "OK, still easy add a dynamic field 'sortinfo_for_*' and fill this for > each group membership." > > Yes, this works, but there are thousands of different groups, that much > dynamic fields are probably a serious performance issue. > - "Well ..." > > I'm looking for a smart way to answer to the question "Find the members of > group X and sort them by the the sortstring for this group". > > One idea I had was to fill the 'member_of' field with composed entrys > (groupname + "_" + sortstring). Finding the members is easy with wildcards > but there seems to be no way to use the sortstring as a boostfactor > > Has anybody solved this problem? > Any hints are welcome. > > Uwe > -- Sincerely yours Mikhail Khludnev Principal Engineer, Grid Dynamics <http://www.griddynamics.com> <mkhlud...@griddynamics.com>
