breeze: behavior of setDeleted

Question

I have a grid which shows a list of entities.

Each row has a delete button.

Once the user clicked on the delete button for a given entity I want to change the css of the row and to replace the delete button with a cancel button.

So on the delete button event handler, I do :

myEntity.entityAspect.setDeleted();

But as soon as I do that, the entity is removed from the collection and the row disappear from the grid.

Is there a way to prevent that ? I just want to mark the entity as 'deleted', and postpone any change until user clicks on save button.

The only alternative I see, is to add a property isDeleted to my client-side model and to base my logic on that. But it means I have to handle change tracking myself and loop through the entities on save to call setDeleted for entities which isDeleted property is true. I'm not fond of this solution. Is there something better I'm missing with breeze ?

Answer 1

The problem with 1) is that when you delete an entity we need to sever its relationships with any other entities. This really is the essence of deleting, we want the environment to look like it will after the delete is committed ( via EntityManager.saveChanges())

When you say that you do not want the navigation properties to be set to null after a delete I am assuming that you are talking about a scalar (1->1) or (n->1) navigation. (nonscalar navigations simply remove the entity from the collection) The first issue is whether you are talking about navigations 'To' the deleted entity or 'From' the deleted entity. In the case of 'NOT" removing the navigation 'to' a deleted entity we would be causing many if not most existing breeze apps to fail. Most apps expect to see entities disappear when you delete them.

In the case of 'NOT' removing the navigation 'from' a deleted entity, the concept make more sense except that you cause two more issues. The first is that this breaks any 'bidirectional' navigations, i.e. you can no longer roundtrip between the 'from' and 'to' navigations. But more importantly, we view a 'delete' as a precursor to an eventual 'detach' operation ( which will occur after a successful save). The primary value of the 'detach' is that it recovers memory because we have effectively removed any references to the 'deleted' object, which means that it can be garbage collected. If we leave any navigation properties intact this garbage collection will never occur, and we end up with a memory leak.

We could get around this by having the 'detach' operation also remove navigation properties but the rules begin to get harder to explain.

If you still feel strongly about this, please post your suggestion to the Breeze User Voice. If we see some substantial interest in this, we will try to come up with a solution, but right now we don't have a good answer to this that doesn't add real conceptual complexity. (Something we really try to avoid).

Can you give more detail about the 'validations' that you are seeing? Are these validations on the 'deleted' entity or on the still alive entities that were pointing to the deleted entity? Not having the first occur makes a lot of sense (and we should fix it if this is the case), not having the second occur does not make sense because you really are causing a real validation failure.

Answer 2

My guess is that your collection is the value of one of Breeze's navigation properties. These collections are 'live' in that if you delete an entity, the entity becomes removed from all live collections to which it belongs.

So the best answer would be to copy the entities into your own collection and bind to that. Your own collection will not be 'live' and deleting entities will not remove them from the collection.

Answer 3

Ok, I have tried Jay's solution. First I do a deep copy using lodash.js:

$scope.sourceMaterials = _.clone($scope.request.sourceMaterials, true);

then I bind my grid to $scope.sourceMaterials. User clicks on delete button for a given row and I do:

var document = $scope.sourceMaterials[index];
document.entityAspect.setDeleted();

The problem is that breeze sets to null all the navigation properties of my entity (see removeFromRelationsCore function in breeze.js).

Doing so affects the values shown on screen to the user. For instance one of the required field gets nulled by breeze. So when user clicks on the save button, the validation fails.

To sum up I have two issues:

1. navigation properties should not be set to null when deleting my entity
2. the validation should not be triggered for an entity that has its state set to deleted

Could you shed some light on this please ?

EDIT

Following Jay's answer, I can confirm that:

1) navigation property is nulled FROM the deleted entity and I'd like that to be prevented somehow

ex: I have an entity Document with a 1 -> 1 np named DocumentType. If I set deleted on Document, then DocumentType is nulled.

2) validation rules occur on properties of the deleted Entity (those that were nulled)

which one of these problems should I report on user voice ?