When you call
Sitecore.ContentSearch.ContentSearchManager.GetIndex(IIndexable indexable), it runs
In the version I'm checking now (it's 8.2 update 3), this pipeline has 1 processor only:
What it does, it takes all the indexex in the order in which they are defined in the config files (see
/sitecore/admin/showconfig.aspx for the order) an for each of them it checks things like:
- Does any of the ancestors of the item is the root of the index provider
- Does the database of the item is same as defined for the index
- Is item excluded from the index
When it finally has all indexes which are valid for the current item, it runs
int SitecoreItemCrawler.GetContextIndexRanking(IIndexable indexable) method. Default implementation returns difference between the index root item level and the indexable item level, so the closer to the index root the better. If there is only 1 index or if the best score from
SitecoreItemCrawler.GetContextIndexRanking method is better then the score of the second index, we have the winner.
If there are 2 or more indexes with same lowest score, Sitecore checks
ContentSearch.DefaultIndexType setting (for Lucene it's
Sitecore.ContentSearch.LuceneProvider.LuceneIndex, Sitecore.ContentSearch.LuceneProvider) and returns first index of that type in alphabetical order.
If there is no index of type matching
ContentSearch.DefaultIndexType, first index of those with lowest score is selected.
There may be some other checks in the other Sitecore versions, but the logic will be similar.
So back to your scenario - when you were passing current item to the
GetIndex method, the other index was winning cause
- either that item was "closer" to the other index root than to your chosen index root
- or it was on the same level in the other index and in your index, but your index type is not same as in the
- or both your and the other index type matches the
ContentSearch.DefaultIndexType setting type but the other index name is alphabetically "lower" than your index name
- or both index types don't match
ContentSearch.DefaultIndexType setting type but the other index is just defined earlier in the config
- or ... well I guess there is some scenario I couldn't think of now :)