Model retrieved by `findRecord` does not update the client on delete

If you retrieve a model by findRecord('something', someId) on one client, then delete that object through a different client, or on the firebase server itself, then the first client doesn’t receive any update.

If you transition to a route that fetches that model, then the model is returned in its previous state to the client (since the local cache doesn’t get updated).

If you tried to retrieve a model via findRecord('something', someId) on one client, and find it didn’t exist (then return a null), then create that object through another client, then the first client doesn’t receive an update that the object got created. This might be harder to deal with, because it is keeping around refs to objects that don’t currently exist on the server simply because it fetched them. This is probably more useful in a compound (“hash”) model.

There is a didDelete method on a model that I’d expect to be called when the object is deleted, and I’d expect the model instance to somehow be purged from the local cache. The challenge there is what to do if it gets recreated.

At the very least, I’d hope to handle the single item delete case so the client can dynamically respond (ask to create it again, do a redirect, post a warning, whatever is necessary).

I think this could be rectified by using 'on' instead of 'once' for the object when fetching it, but I am concerned about E2E expectations on behavior here, and especially in dealing with leaking references. I don’t have enough experience hacking on a data adapter to know that I got my changes right, or what the impact could be on existing clients.

I think this can be worked around by doing a query for the object by key, since the list/query hooks work well, but this does lead to a clunky implementation when you’re really trying to implement single-item data access. It also wouldn’t work if you’re trying to restrict read access to sibling objects.

I think you can also work around it by calling the underlying ref’s on hook: model.ref().on('value', function() { ... });. I saw this recommended as a work-around for Firebase’s transaction support on another bug. This seems like it shouldn’t be a permanent solution, though, because unlike transaction, Ember Data has an interface to support notifications and updating on delete.

[gabrielgrant]

I think this bug description is slightly inaccurate: the record is updated on the client, but it isn’t removed – it remains in the store, with isDeletedand hasDirtyttribues set to true.

@tstirrat I think you’re right that this is caused by the same root problem as #145 – when a record is deleted in FB, the corresponding record should be unloaded from the ED store instead of deleted. Even with that, though, I’m not sure the didDelete event @kavika13 is asking for would fire.

@cs3b The quick-fix workaround is to filter your records to hide deleted records, either using the ember-data-live-filter addon or, if you don’t want the addon, as described here

For more background, see the blog post about this change is ember-data 2.0

[cs3b]

on v1.6.4 this is still a problem - how it is possible to handle it, where to start?