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
Does this have to be in Solr?
Given the pre-computed nature of the sub-series, maybe you can encode both
series name and series sort order in a separate structure designed for it.
Something like Neo4J comes to mind: http://www.neo4j.org/ .
Or, this could be a good question for StackOverflow on wh
Am 08.01.2013 10:26, schrieb Uwe Reh:
OK, OK,
I will try it again with dynamic fields.
NO!
dynamic fields are nice, but not for my problem. :-(
I got more than *52* new fields.
I was wrong, the impact on searching is really reasonable. But have you
ever used the Admin's Schema Browser wit
olr-user@lucene.apache.org
Subject: Re: theory of sets
Dynamic fields resulted in poor response times? How many fields did each
document have? I can't see how a dynamic field should have any
difference from any other field in terms of response time.
Or are you querying across a large numb
his take
too much memory and slow down performance (even if very few fields are really
used)?
Best regards, Lisheng
-Original Message-
From: Upayavira [mailto:u...@odoko.co.uk]
Sent: Monday, January 07, 2013 2:57 PM
To: solr-user@lucene.apache.org
Subject: Re: theory of sets
Dyna
Dynamic fields resulted in poor response times? How many fields did each
document have? I can't see how a dynamic field should have any
difference from any other field in terms of response time.
Or are you querying across a large number of dynamic fields
concurrently? I can imagine that slowing th
Hi Robi,
thank you for the contribution. It's exiting to read, that your index
isn't contaminated by the number of fields. I can't exclude other
mistakes, but my first experience with extensive use of dynamic fields
have been very poor response times.
Even though I found an other solution, I
Hi Uwe,
We have hundreds of dynamic fields but since most of our docs only use some of
them it doesn't seem to be a performance drag. They can be viewed as a sparse
matrix of fields in your indexed docs. Then if you make the
sortinfo_for_groupx an int then that could be used in a function que
Hi,
I found a own hack. It's based on free interpretation of the function
strdist().
Have:
- one multivalued field 'part_of'
- one unique field 'groupsort'
Index each item:
For each group membership:
add groupid to 'part_of'
concat groupid and sortstring to new string
ad
