Examine - in GatheringNodeData event, update a custom field on a different indexed node
I'm using the GatheringNodeData event to add some custom information to an Examine index. Easy enough with e.Fields.Add("name",value) etc.
However, inside my GatheringNodeData event, I also need to locate the entry in the Examine index that corresponds to the indexingDocument's parent node, and update a field on that as well.
I can't do that because the value I need to save in the parent is a *custom value* based on all of its children, and not a property of the parent node doctype.
To be more specific:
- I have a "book" node which can be "tagged" with various properties
- Books can be children of a "series"
- When a "book" is tagged (and then published), I need to take all the tags from this book, and all it's siblings, and add a custom field to the parent ("series") node which contains a full list of all tags of it's children.
So, it's not an actual property, it's a value constructed from other values which should *only exist in the Examine index*.
I think I follow... and can see that ideally you want to direcly access parent record in examine (I can't see any obvious way of getting at this from the GatheringNodeData event - is there a way ?).
Not tried it, but still reckon that re-indexing the parent (series) node could work. In the GatheringNodeData event it coud query down tree to access all the data it needs to index.
In my GatheringNodeData event, if the document being indexed is a "book", then it just adds the custom field with the tags for that book. Then, if the "book" has a parent node of type "series", it re-indexes the parent node.
If the document is a series, then the GatheringNodeData event collates all the tags from all books in that series, and adds the custom field with the collated tags.
This seems like it should work.
However, when I rebuild the index, all "series" nodes appear in my index twice (confirmed by checking with LUKE).
Make sure you are using the latest version of Examine 1.x .
Also, if you dont want to go the path of re-indexing parent nodes, you could use the Examine API to search for your specific record based on an Id, then if you wanted to update the record directly you'd have to build the XDocument from the SearchResult to then call ReIndexNode(...). Off the top of my head i cant remember if there's an extension method to do that already, would assume there is.
I really can't wait to release Examine v2.0 it makes all of this a lot clearer. Examine v1.x was originally just based on the xml structure of Umbraco which isn't ideal for 'any' data. The Umbraco v5 Examine Hive provider is based on Examine v2.0.
Also, i'll be releasing a new Examine 1.4 next week hopefully.
Examine - in GatheringNodeData event, update a custom field on a different indexed node
I'm using the GatheringNodeData event to add some custom information to an Examine index. Easy enough with e.Fields.Add("name",value) etc.
However, inside my GatheringNodeData event, I also need to locate the entry in the Examine index that corresponds to the indexingDocument's parent node, and update a field on that as well.
Possible?
Hi Mike,
This is a guess and It's probably not the most efficient method, but how about just re-saving the parent node, causing it to be re-indexed ?
Hi Hendy
I can't do that because the value I need to save in the parent is a *custom value* based on all of its children, and not a property of the parent node doctype.
To be more specific:
- I have a "book" node which can be "tagged" with various properties
- Books can be children of a "series"
- When a "book" is tagged (and then published), I need to take all the tags from this book, and all it's siblings, and add a custom field to the parent ("series") node which contains a full list of all tags of it's children.
So, it's not an actual property, it's a value constructed from other values which should *only exist in the Examine index*.
Clearer? (not sure it is....)
Mike
Hi Mike,
I think I follow... and can see that ideally you want to direcly access parent record in examine (I can't see any obvious way of getting at this from the GatheringNodeData event - is there a way ?).
Not tried it, but still reckon that re-indexing the parent (series) node could work. In the GatheringNodeData event it coud query down tree to access all the data it needs to index.
Hendy
Hi Hendy
Good thinking - I'm almost there, I think.
In my GatheringNodeData event, if the document being indexed is a "book", then it just adds the custom field with the tags for that book. Then, if the "book" has a parent node of type "series", it re-indexes the parent node.
If the document is a series, then the GatheringNodeData event collates all the tags from all books in that series, and adds the custom field with the collated tags.
This seems like it should work.
However, when I rebuild the index, all "series" nodes appear in my index twice (confirmed by checking with LUKE).
Any ideas?
Mike
Hey Mike,
Make sure you are using the latest version of Examine 1.x .
Also, if you dont want to go the path of re-indexing parent nodes, you could use the Examine API to search for your specific record based on an Id, then if you wanted to update the record directly you'd have to build the XDocument from the SearchResult to then call ReIndexNode(...). Off the top of my head i cant remember if there's an extension method to do that already, would assume there is.
I really can't wait to release Examine v2.0 it makes all of this a lot clearer. Examine v1.x was originally just based on the xml structure of Umbraco which isn't ideal for 'any' data. The Umbraco v5 Examine Hive provider is based on Examine v2.0.
Also, i'll be releasing a new Examine 1.4 next week hopefully.
is working on a reply...