-
Notifications
You must be signed in to change notification settings - Fork 67
Description
Locally I noticed that when working on a query with (some, some, some)
query filter, the index was not updated when I set a new value of a parent. Specifically, the ChatRoom still showed the Message even after I changed the parent of the message to something else. Deletion worked fine, though.
I think remove_atom_from_index
is calling, but should_update
is returning false. Not sure about this.
EDIT:
Here's what's happening. The changed Atom is properly added, and the old one is properly removed. However the change in resource has modified for which Queries it actually fits. So because now the parent
is different, some QueryFilters should no longer match.
The inverse should probably also be true - let's say the change causes a new QueryFilter to match, that did not match previously.
I think this can happen if there is Some(sorted_prop)
and one or two filters (i.e. value, property or both).
So, we only update the Atom for the new parent
. But in this case, the indexed_atom for the created_at
is causing the actual problem. That atom is not actually removed, since created_at
is not mutated.
Solutions:
Remove all atoms for old resource
Seems pretty simple, but also costly. It means that even if we only want to update one value, we have to remove and then add all indexed items of the resource.
Change invalidation logic
So let's assume that we only know the updated atom. Is there a way we can find the existing indexed_atom that should no longer match?
We could find all indexed items where the subject matches, and check if the new resource still fits the query. If the answer is no, we remove the atom from the index.
So, if we check_if_atom_matches_watched_query_filters
for the removal of the old atom, and we get a resource_match
for prop p
, we need to check the following:
does the resource_old
match, and does resource_new
match? No worries. Does resource_old
match, but resource_new
does not? Remove the index atoms!