Closed billdami closed 5 years ago
Could you share the code you're using to authenticate users with Anonymous Auth?
I can confirm this, a record removed on the server will also remove locally, but the deleted record will still be cached locally in the store. This is because we use model.deleteRecord
instead of model.destroyRecord
here.
On the client that deletes the record, as long as you use destroyRecord
it is usually ok:
post.get('id'); // -Jm0LzWtETCIw-LT9ZUP
post.destroyRecord().then(function () {
store.recordForId('user', '-Jm0LzWtETCIw-LT9ZUP'); // undefined
});
But on a different client that observed the delete from the server, the deleted record is still there:
// -Jm0LzWtETCIw-LT9ZUP was deleted on server
store.recordForId('user', '-Jm0LzWtETCIw-LT9ZUP'); // returns the deleted (hidden) record
store.createRecord('user', { id: '-Jm0LzWtETCIw-LT9ZUP', ... });
// Assertion Failed: The id -Jm0LzWtETCIw-LT9ZUP has already been used with another record of type dummy@model:user:.
The workaround is to find the record and unload it manually before creating:
store.recordForId('user', '-Jm0LzWtETCIw-LT9ZUP').unloadRecord();
store.createRecord('user', { id: '-Jm0LzWtETCIw-LT9ZUP', ... }); // works
@tstirrat For the case where there is a different client observing only, how can I manually unload the record?
On some other client, a record with a previously used ID is pushed, the observing client receives the Firebase event and attempts to push the new record (with a re-used ID) into the store, but this is all happening within the emberfire codebase - how can I apply this workaround in my app?
And why not use destroyRecord
? Is there any reason to use deleteRecord
which allows for rollbacks? If we're trying to keep the store in sync with Firebase, committing the change right away with destroyRecord
seems to make sense to me.
@jamiechong Not sure I understand, why does your client have a record with duplicate id in its store if things happened via another client? can you elaborate?
And yes, we should really be doing destroyRecord
or unloadRecord
@tstirrat Sure. Say I'm saving unique records by explicitly setting the id
. In a real-time situation I have one interface (UI-A
) that can CRUD these records and another interface (UI-B
) that merely displays the data.
id="my-unique-id"
, which adds it to its store
.on child_added
event. This adds the my-unique-id
record to the store of UI-B.on child_removed
id="my-unique_id"
.store
of UI-B believes my-unique-id
is still loaded.Also note that I did try replacing deleteRecord
with destroyRecord
on Line 295 just to see if it would work, but it caused all sorts of other issues that I didn't investigate further.
cool, thanks for clarifying that, yes that is a problem
I wonder if unloadRecord
is the most appropriate thing to use instead of destroyRecord
@tstirrat I think unloadRecord
might be used, since destroyRecord
will trigger another server request, which triggers an error response, as stated by @jamiechong.
destroyRecord
is the same as calling deleteRecord
, then save
. More information here: http://guides.emberjs.com/v2.0.0/models/creating-and-deleting-records/#toc_deleting-records
However, unloadRecord only works for non-dirty records so if UI-B is able to change the record before it's informed about the destroy event, it will fail.
Perhaps delete, then unload or unload if delete fails?
I'm inclined to say that using only unloadRecord
is best: if a record has been edited locally before being deleted by another client, that is a legitimate data conflict that should raise an error to allow the client-side code to handle it gracefully (eg. alerting the user that the record has been deleted on the server, and asking if they want to re-create it using their local data, or just lose their changes)
The one potential issue, as raised in #322, is that afaik just calling unloadRecord
will not fire the record's didDelete
event. That being said, I'm not convinced the didDelete
event should fire -- there's a clear difference between a record being deleted locally vs receiving an update from the server. But if the event is desired, then it could just be triggered manually.
In my application, I have what I think is a fairly standard
User
model, whose IDs are based on the authenticated users'fbRef.getAuth().uid
value (which in my case is assigned by the Anonymous authentication provider). I have a global users which dynamically updates as users authenticate/unauthenticate, that is populated using a basicthis.store.find('user')
call.The problem arises when a user signs out, and then re-authenticates/signs in with the same auth uid. I recieve the following error in the consoles of the other currently connected browsers:
(note however, that the user/browser that did the signing out/re-logging in receives no error)
Is there anything else I need to do in this scenario to make sure that records automatically deleted by emberfire are fully committed in each connected client's cached store, or is this a limitation of some sort?
For reference, here is how I am creating the records when a user signs in:
And when they sign out: