ticket: 48497 extended search without MR indexed attribute prevents later indexing with that MR
Bug Description:
When creating a mr_indexer or a mr_filter, we first look if it exists the registered MR (global_mr_oids)
that can handle the required oid.
If there is no registered MR, we look for a MR plugin that can handle this oid.
At the beginning no MR is registered. If the retrieved MR plugin is called to create:
- an indexer it sets in the registered MR the indexer create function(SLAPI_PLUGIN_MR_INDEXER_CREATE_FN)
but not the filter create function (SLAPI_PLUGIN_MR_FILTER_CREATE_FN).
- a filter it sets in the registered MR the filter create function (SLAPI_PLUGIN_MR_FILTER_CREATE_FN)
but not SLAPI_PLUGIN_MR_INDEXER_CREATE_FN.
The consequence is that the registered MR may be missing filter or indexer create fn.
It ends with different wrong behaviors:
1 - for example if we index (e.g. msMatchingRule: caseExactIA5Match) it registers 'caseExactIA5Match',
MR plugin with the indexer create function.
Then if we issue a filter with ": caseExactIA5Match:' it will not find the registered MR
(because it is missing SLAPI_PLUGIN_MR_FILTER_CREATE_FN), so it will register once
again the same MR plugin but this time with the filter create function.
2 - for example if we issue a filter with ": caseExactIA5Match:' it registers 'caseExactIA5Match',
MR plugin with the filter create function.
Then if we index 'msMatchingRule: caseExactIA5Match', it will retrieve the registered MR plugin
but has it has no indexer create function, it fails to index.
Fix Description:
When registering a MR plugin, sets both indexer and filter create functions
https://fedorahosted.org/389/ticket/48746
Reviewed by: Mark Reynolds, Rich Megginson (thanks Mark, thanks Rich !!)
Platforms tested: F17
Flag Day: no
Doc impact: no