The old umbSearch used to index all specified properties but also used to do a separate field called content that was a combination of all those properties. So for example if you wanted to serach for the word umbraco in all your fields you could just search on content field in index. Looking at the index created by examine you dont have this combined field so am i right in assuming i would need to do something like
Yeah we don't combine the data into a single field, you can use the GatheringNodeData or DocumentWriting event (depending on whether you want to just add a combined field to the collection or you want complete control over how it's handed within Lucene itself).
I'd recommend GatheringNodeData as the event, then you just need to loop through the fields in the event arg, get the content and add it to your own field.
Actually, up until we built the fluent API, examine had this functionality built in... The first overload for searching that doesn't use the Fluent API should actually search all non-system fields.
I don't think it would be too difficult to add another extension method to the Fluent API to have .AllFields() or something..?
Yeah you can use the non-fluent API method, it iterates over all the fields defined in the config, it wont handle any custom fields you've inserts yourself.
I'd still go with having a separate field cuz then you can have only some of the fields, not all, as for free text searching you may want to exclude things like NodeTypeAlias.
Examine search question
Slace or Shawwaza,
The old umbSearch used to index all specified properties but also used to do a separate field called content that was a combination of all those properties. So for example if you wanted to serach for the word umbraco in all your fields you could just search on content field in index. Looking at the index created by examine you dont have this combined field so am i right in assuming i would need to do something like
and so forth for all the fields?
Ps great work guys examine totally rocks!
Regards
Ismail
Yeah we don't combine the data into a single field, you can use the GatheringNodeData or DocumentWriting event (depending on whether you want to just add a combined field to the collection or you want complete control over how it's handed within Lucene itself).
I'd recommend GatheringNodeData as the event, then you just need to loop through the fields in the event arg, get the content and add it to your own field.
Actually, up until we built the fluent API, examine had this functionality built in... The first overload for searching that doesn't use the Fluent API should actually search all non-system fields.
I don't think it would be too difficult to add another extension method to the Fluent API to have .AllFields() or something..?
Yeah you can use the non-fluent API method, it iterates over all the fields defined in the config, it wont handle any custom fields you've inserts yourself.
I'd still go with having a separate field cuz then you can have only some of the fields, not all, as for free text searching you may want to exclude things like NodeTypeAlias.
is working on a reply...
This forum is in read-only mode while we transition to the new forum.
You can continue this topic on the new forum by tapping the "Continue discussion" link below.