You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am using Hasura + Postgres to host my data models. In those models I have "sources" each of which can be connected from many "sinks". E.g. source_id is a FK in sinks table to an entry in sources. Hasura then represents this as an "array relationship" to a field in sources called assignedSinks.
I've scaffolded my models through mst-gql and loaded the code into my React Native app successfully, am able to query the data using the gen'd queries and that all is mostly fine. I have two concerns:
if I try to clear the data in the client using the generated stores' .clear() functions I get an error telling me that each of the sinks was already deleted earlier.
Error: [mobx-state-tree] You are trying to read or write to an object that is no longer part of a state tree. (Object type: 'Sources, Path upon death: '/sources/11669502-f315-4938-a95e-14ed769a7718', Subpath: 'assignedSinks'
In plain old mobx-state-tree safeReference can protect and cascade deletes so that this doesn't happen but it looks like mst-gql isn't use safeReferences.
2a) FYI I'm clearing the models first because of something related: if I run a mutation against the data that nulls out the FK value between the tables (e.g. set sinks.source_id = null, and return only sinks row, then the corresponding source's assignedUpdates is not updated at once. I think it's because Hasura delays nested updates to related tables. That's a bit too bad, don't know how to solve.
2b) But while testing that problem, I deleted a few sinks from my test data and noticed that when I refreshed my app with data from the server mst-gql's merge() functionality didn't seem to remove sinks that no longer existed on the server. I have no idea why. Perhaps the local cache? Perhaps merge can't detect deletes (how could it)? Ergo I started trying to clear out data first - see 1).
Am I doing some of these things wrong in mst-gql?
I'd be curious for any insights, thanks!
The text was updated successfully, but these errors were encountered:
HI @pkreipke Im trying to help @jesse-savary clean up all outstanding issues... I understand this message was send back in July - Do you still have the same questions?
I am using Hasura + Postgres to host my data models. In those models I have "sources" each of which can be connected from many "sinks". E.g.
source_id
is a FK insinks
table to an entry insources
. Hasura then represents this as an "array relationship" to a field insources
calledassignedSinks
.In memory:
I've scaffolded my models through
mst-gql
and loaded the code into my React Native app successfully, am able to query the data using the gen'd queries and that all is mostly fine. I have two concerns:.clear()
functions I get an error telling me that each of thesinks
was already deleted earlier.In plain old mobx-state-tree
safeReference
can protect and cascade deletes so that this doesn't happen but it looks like mst-gql isn't use safeReferences.2a) FYI I'm clearing the models first because of something related: if I run a mutation against the data that nulls out the FK value between the tables (e.g. set
sinks.source_id = null
, and return onlysinks
row, then the corresponding source'sassignedUpdates
is not updated at once. I think it's because Hasura delays nested updates to related tables. That's a bit too bad, don't know how to solve.2b) But while testing that problem, I deleted a few
sinks
from my test data and noticed that when I refreshed my app with data from the servermst-gql
'smerge()
functionality didn't seem to removesinks
that no longer existed on the server. I have no idea why. Perhaps the local cache? Perhaps merge can't detect deletes (how could it)? Ergo I started trying to clear out data first - see 1).Am I doing some of these things wrong in mst-gql?
I'd be curious for any insights, thanks!
The text was updated successfully, but these errors were encountered: