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 resources. Sure we could try to run a solr query for this, and maybe add 
index fields for it, but we felt it better to run this on the index-trigger 
side, the thing in our (XWiki) wiki which listens to changes and requests the 
reindexing of a few documents (including deletions).

For the maintenance operation, the same issue has appeared.
So, if the indexer or listener or solr has been down for a few minutes or 
hours, we'd need to reindex not only all changed documents but all changed 
documents and their related documents.

If you are able to work through your solution that would be solr-only,  to 
write down all depends-on at index time, it means you would index-update all 
"inverse related" documents every time that changes. For the relation above 
(documents of a user), it means the user documents needs reindexing every time 
a new document is added. I wonder if this makes a scale difference.

Paul


Le 27 nov. 2013 à 09:13, Thomas Scheffler <thomas.scheff...@uni-jena.de> a 
écrit :

> Hi,
> 
> I am relatively new to SOLR and I am looking for a neat way to implement weak 
> documents with SOLR.
> 
> Whenever a document is updated or deleted all it's dependent documents should 
> be removed from the index. In other words they exist as long as the document 
> exist they refer to when they were indexed - in that specific version. On 
> "update" they will be indexed after their master document.
> 
> I could like to have some kind of "dependsOn" field that carries the 
> uniqueKey value of the master document.
> 
> Can this be done efficiently with SOLR?
> 
> I need this technique because on update and on delete I don't know how many 
> dependent documents exists in the SOLR index. Especially for batch index 
> processes, I need a more efficient way than query before every update or 
> delete.
> 
> kind regards,
> 
> Thomas

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to