[Edit]
It might be much easier to actually save a separated field and index it (via Computed field module or with a hook).
[Original]
I did some research before opening this issue, however am confused and asking for help :)
GIVEN
- Two fields: 1. Year born; 2. First year of activity. Each uses a simple integer datatype.
- A view using indexed search api filters.
NEED
- Return results having a value bigger than or equal to the entered value in any of the fields, using a single filter.
IMPLEMENTATION
I have digged (not too deep yet) but not sure which direction to go... I did not find any way to do it using the interface nor proper documentation.
- Is hook_search_api_views_query_alter a way to start? If yes, then what?
- How should I change (or add) conditions?
Thanks for your help!
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | nodecustom.module.remove.txt | 1.77 KB | amir simantov |
| #2 | 2359201-2--add_list_aggregation.patch | 1.73 KB | drunken monkey |
Comments
Comment #1
amir simantov commentedComment #2
drunken monkeyYes, creating a separate field for this would definitely be a good option. There are several options for that available:
hook_entity_property_info_alter(), the Computed Field module, or a custom Search API data alteration. Using Search API's built-in "Aggregated fields" data alteration would be easiest and cleanest, but that sadly doesn't support creating a multi-valued collection of field values.So, let's fix that: the attached patch adds a new "List" field type for that. Please test – it should be exactly what you're looking for!
(We just need to remember to port the patch to D8 afterwards.)
Using an alter hook would also work, but be more complicated and require custom code, of course. I can tell you how to use that, too, if you want, though.
Comment #3
drunken monkeyComment #4
drunken monkeyComment #5
amir simantov commentedHi Thomas and thank you for your help.
Situation gets a bit complicated due to some other issue: #2360427: Cannot add an aggregated field of an index as a filter in a view
Anyway, regarding my specific need, I used the separated field approach and it works fine (I attach the code, to help in case someone falls upon it). As you took the time to code it for me, I wanted indeed to test it even I am not going to use it. However, before applying the patch, I wanted to see what I get without it. I confess I did not see the aggregated fields option before... The steps I took are detailed in the issue mentioned above.
Once the above issue is resolved, I will be happy to check the aggregated fields and test the patch.
Thanks again, Amir
Comment #6
drunken monkeyI'm pretty sure there's nothing in this patch that could go wrong. So, committed.