Skip to content

Guarding against detach and EntityManager clearing #7

@wardbell

Description

@wardbell

Currently you allow Aurelia to continue binding to detached entities.

Why? In theory, one shouldn't be displaying a detached entity and there is no good reason to care about subsequent changes to a detached entity. You might as well unsubscribe.

I realize that Breeze still raises propertyChanged when you set the property of a detached entity. Do we care?

If we don't care, we should discard the BreezeObservableObject (boo) when the entity becomes detached.

When are entities detached?

An entity can become detached for a number of reasons.

  • you detach it programmatically
  • you deleted an unsaved new entity
  • you called rejectChanges on an unsaved new entity
  • after a successful save of an entity marked for delete
  • after clearing the EntityManager

What if we re-attach a detached entity?

Hmmm. If a view is bound to entity "x" . You detach it by one of the mechanisms just described. Then somehow you re-attached it behind the scenes without ever changing its view binding?

I'm not sure what happens. Aurelia probably thinks that the object's bound properties are observable and will be waiting for those callbacks to fire.

I personally don't think this scenario makes practical sense. You shouldn't put the user in this situation anyway. When an entity is detached it should be removed from view.

But I'm open to a counter argument.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions