Adapter (from server) should be able to undelete things about data

[indirect]

[wagenet]

@pixelcort Honestly, I can't see how this would ever be a common case. Once something is deleted, it's gone. I can't see that you'd ever want to resurrect an actually deleted item. If you want "Trash Can" like functionality, then you should implement separately from deletion.

[pixelcort]

That's too bad. On my current ember app and the last few SC apps, all three APIs had cases where things deleted would come back.

Once again, I would have closed this issue which I opened myself, but apparently it was closed for me. I can't believe it's normal on GitHub for issues to be closed by anyone other than the person who opened them.

[pixelcort]

The common case are types of things that have composited ids derived from other things. Conceptually you can think of them deleted, but then later when someone else creates an identical thing, that new thing coincidentally has the same id due to the id being derived from its data.

[pixelcort]

Perhaps instead of undelete, a better explanation is, after something is deleted, something new is made that coincidentally has the same id.

[wagenet]

@pixelcort That explanation makes a bit more sense, I'll reopen for @tomdale and @wycats to review.

As for closing tickets, I'm an admin on this project so I take it that I'm in a position to close tickets. Whenever I close tickets, I always review any additional responses and will reopen if a good argument is put forth.

[wagenet]

I should say however that it seems very odd for the same ids to be reused, even for similar/identical data. I would recommend changing the API over us changing ember-data.

[wagenet]

Crap, that close was accidental.

[pixelcort]

Yeah one example is a User - Subscriber - Chatroom relationship, where Subscriber id is the composite of the user name and the chatroom name. To unsubscribe from a chatroom, the app would send a DELETE /subscriber/pixelcort-cats . Later, if I were to re-join that cats chatroom, the server would create a new subscriber object with the same 'pixelcort-cats' id.

As more servers move to NoSQL-based databases, I think we're going to see more cases where ids are not going to be serially incrementing integers.

@wagenet , sorry about getting upset about the ticket closing; I'm still getting used to GitHub etiquette and came from a place with different cultural beliefs about who was expected to close tickets.

[wagenet]

@pixelcort Sorry to cause offense. I hope it makes a little more sense now. I try to stay aggressive on closing tickets otherwise too many build up and it's hard to track them all. Anyway, I'm leaving this one for Tom and Yehuda to discuss.

[wycats]

One approach for us to use would be to totally remove a record from the store once it has been marked by the server as confirmed deleted. Would this work for you?

[pixelcort]

@wycats that should work; as the new instances that come in later on would get put into various DS.AdapterPopulatedModelArrays.

[jfgirard]

Hi,
one other use case for resurrecting a deleted item is when there is a conflict on commit. In the case of somebody else modified the record just before i commit the deleted record, the server will reject the commit with a conflict flag. Sometimes, the right thing to do will be to put back the record because the update made by an other user make the delete action invalid. I need to move the record from state "deleted.inFlight" to "loaded.saved" and repopulate the modelarrays. I got <DS.StateManager:ember555> could not respond to event didChangeData in state rootState.deleted.inFlight. if I try to update the deleted record...

[wagenet]

@wycats do we remove the record from the store now?

[sly7-7]

@wagenet I think this is the purpose of unloading records #200

[igorT]

So I believe unload fixes this, and this hasn't been active for a while so closing.