Right. Delete by query "id:foo OR dependsOn:foo". --wunder
On Nov 27, 2013, at 6:23 AM, "Jack Krupansky" wrote:
> Just bite the bullet and do the query at your application level. I mean,
> Solr/Lucene would have to do the same amount of work internally anyway. If
> the perceived performance o
Just bite the bullet and do the query at your application level. I mean,
Solr/Lucene would have to do the same amount of work internally anyway. If
the perceived performance overhead is too great, get beefier hardware.
-- Jack Krupansky
-Original Message-
From: Thomas Scheffler
Sent:
Am 27.11.2013 09:58, schrieb Paul Libbrecht:
Thomas,
our experience with Curriki.org is that evaluating what I call the
"related documents" is a procedure that needs access to the complete
content and thus is run at the DB level and no thte sold-level.
For example, if a user changes a part of i
Thomas,
our experience with Curriki.org is that evaluating what I call the "related
documents" is a procedure that needs access to the complete content and thus is
run at the DB level and no thte sold-level.
For example, if a user changes a part of its name, we need to reindex all of
his resou
Just a guess, I haven't investigated them fully yet, but I wonder if
block joins could serve you here, as they involve creating docs in a
parent child relationship.
Or, you could easily fake it:
abcd
parent:abcd
Not sure if that syntax is completely right, but using that sort of
thing woul
