Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
The CollectDatasource plugin for Search API contains some obscure tricks to make properties of multiple schema configs available simultaneously. After selecting the Collect plugin, you can choose which schemas should be included, and then the union of their fields are available as sub-properties under the schemas.
This makes the code and the UI overly complex.
A possibility that has been overlooked is to derive datasource plugins from schema configs. Thus the intermediate step of grouping properties per schema is eliminated.
Search API already natively supports selecting multiple datasources for an index, so the possibility to include multiple schemas is retained.
Proposed resolution
Create a deriver for the datasource plugin, which creates one derivative for each schema config.
Adapt the plugin to being defined for a single schema config.
Remaining tasks
User interface changes
API changes
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | derive-datasource-2492731-3.patch | 16.66 KB | Arla |
| #2 | derive-datasource-2492731-2.patch | 14.62 KB | Arla |
| #2 | Collect index.png | 85.1 KB | Arla |
| #2 | Screen Shot 2015-05-27 at 12.27.52.png | 32.31 KB | Arla |
| #2 | Screen Shot 2015-05-27 at 12.29.00.png | 53.62 KB | Arla |
Comments
Comment #1
miro_dietikerThere is a disadvantage of this approach.
If multiple datasources define a common field, it will result in multiple fields. They can not be indexed as a common one with this approach.
There are other approaches to deal with this problem. This is in general what was discussed under the term mapping.
We need to map multiple separate definitions into a common space so that collect processing creates this common denominator.
Before switching, we need to understand the side effects and how this mapping would could be implemented. And then, we need to decide if/hoch much of it we require to be implemented first or as a followup.
And since this changes data storage of index and need reconfiguration of everything, it is major.
Comment #2
ArlaIssue summary has a screenshot of field configuration before the patch. Here's also a screenshot of the index configuration:
Now here's screenshots from index and field configuration after the patch:
Comment #3
ArlaRerolled.
Tested manually by installing collect_demo. The search page looks as expected, and new containers are automatically indexed.
Comment #8
ArlaLet's discuss whether this is an useful change or not.
To counter #1:
This is actually also the case with the current single-plugin approach. The interesting feature of "semantic cross-domain property mapping" (as I would name it) is thus quite separate from this issue.
Another disadvantage with this approach is that an index can no longer be configured as "all models except X and Y". With one datasource per model, they must be positively selected. I'm not sure how much of a problem that is.
Comment #9
miro_dietikerThe "all" problem is not relevant.
Each of the plugins has separate structure of data. Just enabling all sources will not lead to any job done. You will always need to enable the fields additionally.
So i agree, it's much more different entity types (different sources) than bundles / variants if a specific entity type.
- Without the mapping, the definitions are separate anyway.
- With the mapping, we can also cover the type relation of bundles.
Comment #10
ArlaCool, then let's commit it. I just tested manually again, with success.
Comment #12
ArlaCommitted and pushed!