-
Notifications
You must be signed in to change notification settings - Fork 5
Description
For now, the WS is send inside the move transaction. It should be send after to allow the query-client to invalidate the queries correctly.
Current state and problems
sequenceDiagram
participant Client
participant Server
Client ->> Server: Move items
Server -->> Client: HTTP 202 Accepted
par in the transaction
critical transaction
loop Move items
Server ->>+ Server: Move item
Server -->> Client: ws { op: 'delete', source: item }
Client ->> Client: useChildrenUpdates manually update cache for source
Server -->>- Client: ws { op: 'create', destination: item }
Client ->> Client: useChildrenUpdates manually update cache for destination
Server -->> Client: Websocket feedback
Client ->> Client: useItemFeedbackUpdates display message
end
end
and sending when transaction is not terminated
Client ->> Server: GET item [id]
Server -->> Client: HTTP 200 with staled item (still in transaction)
end
The problem here is that when we want to use useChildren with a filter (like the type of the item), a new key is created (something like ['items', 'children', $id,['FOLDER]). To be sure to update correctly the data, it may be mandatory to update all the children caches. The problem with that, is we have to update caches correctly depending on the filter applied on them.
Another problem is that manipulating the cache manually can cause issues and it is error prone. But for now it is not possible to invalidate the cache. Indeed, a new request will be send to the server, but because the transaction is not terminated, the staled data will be sent.
Ideal solution
sequenceDiagram
participant Client
participant Server
Client ->> Server: Move items
Server -->> Client: HTTP 202 Accepted
loop Move items
critical transaction
Server ->> Server: Move item
end
Server -->> Client: ws { op: 'delete', source: item }
Client ->> Client: useChildrenUpdates invalidate cache source
Client ->> Server: GET item source
Server -->> Client: HTTP 200 with correct committed item
Server -->> Client: ws { op: 'create', destination: item }
Client ->> Client: useChildrenUpdates invalidate cache destination
Client ->> Server: GET item [id]
Server -->> Client: HTTP 200 with correct committed item
end
Server -->> Client: Websocket feedback
Client ->> Client: useItemFeedbackUpdates display message
Ideally, the query-client should invalidate the cache for the source and destination parent items and should receive the correct committed data.
This allows to notify user concerning successful and errors, as well as not rolling back successful moved items (comparing to previous implementation).