Using search_api_db with a custom entity.
Changed Index-field-type for a textfield from Fulltext to String.
This creates a new table 'search_api_db_[index-name]_entity_[entity-type]_[field-name]' with two columns, 'item_id' and something like 'entity_[entity-type]_[field-name]'.
The indexing itself however will try to use a column "value", which does not exist.
On a first glimpse Database.php => line 1114
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 2616268-7--switch_field_type_db_backend--tests_only.patch | 1.43 KB | drunken monkey |
| #7 | 2616268-7--switch_field_type_db_backend.patch | 2.12 KB | drunken monkey |
Comments
Comment #2
christianadamski commentedComment #3
christianadamski commentedUsing $fields[$name]['column'] at line 1117 does not work either, because the 'language' table actually uses "value". Darn
Comment #4
christianadamski commentedThis is what made indexing work again here.
Comment #5
christianadamski commentedComment #7
drunken monkeyI think the actual solution is much more simple: the problem is just that, since the field only changes and isn't new, the old values the server has saved for the field are "bleeding" through. And while the code assumes that only the
'table'key exists in that info array when being handed tocreateFieldTable(), it actually has'column'still set from before, resulting in an unexpected column name.Comment #9
drunken monkeyComment #10
borisson_The regression test is very clear, so because that passes, I'm pretty confident that the bug will gone with this patch committed.
Comment #12
drunken monkeyGreat to hear, thanks for reviewing!
Committed.