The Multi-Index Searches module, as it currently is, is not very useful, as nearly all contrib extensions have to be re-implemented for it, due to it using a completely separate search system. It might have been the best way to be implemented back when it was written, but I think we should be able to do better in D8, and should do so.

Why is this issue in the Search API project? Because I want to keep the use case of the Multi-Index Searches module in my mind while making decisions about API changes in D8, so we can implement this as cleanly and usefully as possible.

My currently favored idea would be to move away from doing this at query time, but rather to allow indexes to have several different item types. By defining a data source controller doing that, this would already be possible, and with #2044419: Make datasource controllers more powerful it would get a lot easier. Does this sound reasonable to you? I admit, having to create a new index to be able to do multi-type searches is a bit more work than before – but on the other hand, if we do it properly, this would be the only search index you'd need on the site, because you could filter for the different item types in the type-specific searches.

Now, what would be missing for that idea? I think the largest drawback currently, when implementing it like this, would be that all entity-specific extensions wouldn't work, as getEntityType() can only return a single type. But I wouldn't really know how to handle multiple entity types returned from that (or a similar) method – usually we need to know a single one. Maybe building the multi-type support deeper into the API and having an always-present search_api_type field on all items, that maybe would even have to be returned from searches, would be the solution. But that would be a rather large change, and I'd be reluctant to do that unless I know it's necessary and useful enough.

The other thing is related to that, with processors like Node Access not working for Multi queries. With the required type field this would be solved, but the question is whether there are also other ways to do that.

So, any feedback on this? Anything to add? Does maybe someone have some other vision/idea for how to overhaul the Multi module for D8?

Comments

The more I think about it, the more I like the idea of just letting an index have more than one item type. It would ensure that this use case is really throughly supported by all parts of the Search API and related projects. The way I see it, there would then be several datasource controllers attached to an index, one per each item type. Where we now use the datasource controller for an operation, we would then use the one for the appropriate type, or loop over all of them. And of course, when handling items to index or results returned from a search, we'd always have to keep track of which item belongs to which type. (Maybe result items should just be proper objects, with methods to load them, get a metadata wrapper (or whatever they are called in D8), get their type or other metadata and maybe view them, etc.) The item ID would then automatically always be a string, consisting of the item type, some separator, and whatever type-specific ID the item normally has.

While I think this wouldn't be to hard to implement in most parts of the framework, at least the admin UI will then need some serious re-vamping. Especially the Fields table, if we would keep it as-is, would then be finally completely overstrained and just become an unusable mess.
Maybe some UX expert would be able to help us there, though I would also have some ideas myself.

Other than that, I'd be very eager to hear what others have to say here! Do you agree this change would make sense? Can you maybe think of some serious blocking problems we would have here? What's your opinion?

In any case, we should probably decide this rather sooner than later, so we can already keep it in mind or even implement it while doing the major parts of the porting.