Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
If a datasource gets removed from an index, corresponding entities are deleted from the index. But their field configurations remain in an illegal state once the index entity is loaded again from the database.
I suggest to remove all field configurations from an index that depend on a removed datasource.
Comment | File | Size | Author |
---|---|---|---|
#15 | 2761719-14--datasource_removal_cascading_to_fields.patch | 1.82 KB | drunken monkey |
| |||
#15 | 2761719-14--datasource_removal_cascading_to_fields--tests_only.patch | 968 bytes | drunken monkey |
Comments
Comment #2
mkalkbrennerComment #4
mkalkbrennerComment #5
mkalkbrennerI think this version of the patch better demonstrates the issue and is closer to the use case we have in the Solr backend.
Comment #6
mkalkbrennerComment #8
mkalkbrennerComment #9
drunken monkeyThanks a lot for reporting this, it's indeed a pretty big problem. It also occurs when removing a processor that defines a field. The solution will probably be for both problems, though: when saving the index, just get all properties and check that all fields correspond to one of them.
Comment #10
drunken monkeySee #2612104: Cascade properly when processors providing new properties are disabled.
Comment #11
mkalkbrennerThe issue is not solved by the other one.
Comment #13
mkalkbrennerThe test only patch still demonstrates the issue.
Comment #14
mkalkbrennerComment #15
drunken monkeyYou're right, this still leads to errors, even though the bug is now a different one.
The attached patch should fix this, and provide a proper test.
Comment #17
mkalkbrennerThe patch improves the situation. But now the tests in search_api_solr fail on the next query because $query->getSorts() seems to still return the old fields.
Comment #18
drunken monkeyCould you please elaborate on that? What "next query"? What "
$query->getSorts()
"? And why wouldgetSorts()
have anything to do with this issue – that's a simple getter which returns the exact information you put into it before, without any regards to the index's field (or any other) settings.Also, again, failing Solr tests are no grounds for rejection of a patch here. Either tell me what's wrong with the patch itself, regarding just Search API, or fix Solr to work with it.
Comment #19
mkalkbrennerI think the issue isn't completely fixed. The broken solr tests are still broken in a part that only consists of calls to search api functions. So I think it's not solr related but discovers a remaining search api bug if a datasource gets removed. I'm currently trying to reproduce the issue in an search api only tests and will create another issue for that.
Comment #20
mkalkbrennersorry, the issue hasn't been committed so far, so back to needs review.
Comment #21
mkalkbrennerOK, I found the reason that still breaks the solr tests even with the proposed patch applied:
This function from the BackendTestBase randomly adds 'id' as sort parameter which doesn't exist anymore if datasource entity:entity_test_mulrev_changed gets removed. Due to that alteration between 'id' and 'search_api_id', the query worked on one index but failed on the second I use in the solr tests.
Please excuse the confusion. The patch solves the issue and is RTBC.
Comment #23
drunken monkeyOK, good to hear, thanks!
Committed.