I currently have an Examine index which writes tags and MNTP property values into a custom field in the index. It's working well, but now the requirement is to search only content of a particular document type. Sometimes the search will need to search only 'article' document types. Sometimes it will search only 'product' document types.
Currently this is being done by passing the document type alias to the index like this as it builds the query:
However, I'm seeing a mixture of document types appear in the results here, so what I'm thinking is that searching this way is only 'loose' in that the document type is only one of the search criteria considered, and it's not exclusive.
Sooo... am I best creating a new index for each document type, or is there a way to make the document type part of the query exclusive, so that only document types of 'Product' will be returned if that's what's passed to it?
My gut instinct suggests it'd be neater just to deal with a single index, but I'm open to suggestions!
I am assuming you are building the query raw using strings to give the final lucene syntax query? I on numerious occasions done doc type searches and it only comes back with the specific doc type however I have always used the fluent api e.g
BaseSearchProvider _searcher = ExamineManager.Instance.SearchProviderCollection["myindex"];
var criteria = _searcher.CreateSearchCriteria(IndexTypes.Content);
IBooleanOperation examineQuery;
IExamineValue cleanKeyword = searchTerm.MakeSearchQuerySafe().MultipleCharacterWildcard();
examineQuery = criteria.Field(Constants.Examine.IndexFieldAliases.Contents, cleanKeyword);
examineQuery = AddNodeTypeAliasFilter(nodeTypeAliases, examineQuery);
/// <summary>
/// append all nodetype aliases to the query to filter on
/// </summary>
/// <param name="nodeTypeAliases"></param>
/// <param name="queryToBuild"></param>
/// <returns></returns>
private IBooleanOperation AddNodeTypeAliasFilter(IEnumerable<string> nodeTypeAliases,
IBooleanOperation queryToBuild)
{
var fields = new List<string> {"nodeTypeAlias"};
queryToBuild.And().GroupedOr(fields, nodeTypeAliases.ToArray());
return queryToBuild;
}
Thanks Ismail, yes, I'm building up a raw query using strings. Actually I've just read the old faithful blog post about Examine and I'm experimenting with this, which looks promising (adding the plus to the query to make it HAVE to include that node type alias):
I'm having a couple of server access issues at the moment so not able to test whether this is working, but I'll report back. If not, I'll try the fluent API as per your example.
The + will sort it. One thing i would also search on nodeTypeAlias and not __NodeTypeAlias anything in the index with __ is used for sorting purposes. Also you can test your queries using ExamineInspector (http://our.umbraco.org/projects/backoffice-extensions/examine-inspector) if you install that then you do not need server access.
Clarification on limiting Examine search to particular document type
Hi,
I currently have an Examine index which writes tags and MNTP property values into a custom field in the index. It's working well, but now the requirement is to search only content of a particular document type. Sometimes the search will need to search only 'article' document types. Sometimes it will search only 'product' document types.
Currently this is being done by passing the document type alias to the index like this as it builds the query:
However, I'm seeing a mixture of document types appear in the results here, so what I'm thinking is that searching this way is only 'loose' in that the document type is only one of the search criteria considered, and it's not exclusive.
Sooo... am I best creating a new index for each document type, or is there a way to make the document type part of the query exclusive, so that only document types of 'Product' will be returned if that's what's passed to it?
My gut instinct suggests it'd be neater just to deal with a single index, but I'm open to suggestions!
Any pointers appreciated, thanks folks.
Dan,
I am assuming you are building the query raw using strings to give the final lucene syntax query? I on numerious occasions done doc type searches and it only comes back with the specific doc type however I have always used the fluent api e.g
BaseSearchProvider _searcher = ExamineManager.Instance.SearchProviderCollection["myindex"]; var criteria = _searcher.CreateSearchCriteria(IndexTypes.Content); IBooleanOperation examineQuery; IExamineValue cleanKeyword = searchTerm.MakeSearchQuerySafe().MultipleCharacterWildcard(); examineQuery = criteria.Field(Constants.Examine.IndexFieldAliases.Contents, cleanKeyword); examineQuery = AddNodeTypeAliasFilter(nodeTypeAliases, examineQuery); /// <summary> /// append all nodetype aliases to the query to filter on /// </summary> /// <param name="nodeTypeAliases"></param> /// <param name="queryToBuild"></param> /// <returns></returns> private IBooleanOperation AddNodeTypeAliasFilter(IEnumerable<string> nodeTypeAliases, IBooleanOperation queryToBuild) { var fields = new List<string> {"nodeTypeAlias"}; queryToBuild.And().GroupedOr(fields, nodeTypeAliases.ToArray()); return queryToBuild; }Thanks Ismail, yes, I'm building up a raw query using strings. Actually I've just read the old faithful blog post about Examine and I'm experimenting with this, which looks promising (adding the plus to the query to make it HAVE to include that node type alias):
I'm having a couple of server access issues at the moment so not able to test whether this is working, but I'll report back. If not, I'll try the fluent API as per your example.
Thanks again.
Dan,
The + will sort it. One thing i would also search on nodeTypeAlias and not __NodeTypeAlias anything in the index with __ is used for sorting purposes. Also you can test your queries using ExamineInspector (http://our.umbraco.org/projects/backoffice-extensions/examine-inspector) if you install that then you do not need server access.
Regards
Ismail
Excellent, it does indeed sort it! And thanks for your blog/forum posts etc on Examine, it's all really useful stuff. #h5yr :)
is working on a reply...