DB stores settings_id as machine name, but rules config sends numeric id for query...
Looking at the table schema, the search_api_saved_searches table stores the settings_id as varchar.
The rules configuration for the "Fetch the saved searches" action stores the search index setting as the numeric ID of the saved search settings.
During rule execution, this numeric settings ID is passed to search_api_saved_searches_get_searches_to_be_executed() which then adds a query condition to compare the numeric settings ID to the settings_id column on the search_api_saved_searches table. Since the field in the DB is varchar, the query always fails.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 2907340-3--fix_rules_integration.patch | 1.5 KB | drunken monkey |
Comments
Comment #2
classiccut commentedHere's a patch that fixes the issue by doing an inner join with the search_api_saved_searches_settings table.
Comment #3
drunken monkeyThanks for reporting this problem!
It seems with this bug we're also violating our own documentation (function doc comment), so this is definitely a bug (even though I can't know right now what parameter Rules really passes). However, since changing this now would unnecessarily break compatibility, I think it's a safer idea to allow calls with both machine name and ID. (Also, the machine name is
delta, notindex_id.)Please see the attached patch and tell me whether that also resolves the issue for you! (I think it's also cleaner with a separate query instead of a JOIN.)
Comment #5
drunken monkeyWell, it seems like it should work, so just committed it.
Thanks again for reporting!