ViewInstanceDeletion

[asgerhallas]

There's a test named ViewInstanceDeletion which is currently skipped. Shouldn't we be able to delete view instances? Why is it skipped?

[mookid8000]

It's skipped because we (currently) cannot delete view instances :)

And we can't delete view instances because that functionality was never made, because noone actually seemed to need it, because I have yet to see a case where it cannot be worked around, and because it raises a bunch of questions.

E.g., if a view decides to delete itself (by calling context.MarkAsDeleted() or something like that), what should happen if the next event happens to yield the deleted view's ID? should it re-appear? should it stay deleted?

Also, I never found an elegant way of passing the fact that the view called context.MarkAsDeleted() to the view manager, although that part will be pretty easy not that the view context has an items bag.

Thoughts?

[asgerhallas]

Yes, that's what I thought :)

My initial thought was to just have IsDeleted information on the view it self - until I saw the test. I think we should just delete the test and let the view implementer handle it any way he/she finds appropriate for the given situation.

[sdebruyn]

I'm currently using soft deletes, but some views will grow very big, which is not ideal. It's not a priority, but this feature would be nice to have and we should think about how to handle this.

E.g., if a view decides to delete itself (by calling context.MarkAsDeleted() or something like that), what should happen if the next event happens to yield the deleted view's ID? should it re-appear? should it stay deleted?

I have create and delete events for each aggregate root. A root can only be created with a CreatedEvent. So if I fire off a CreatedEvent for an aggregate root that has been soft deleted, I make them re-appear. Every other event fails because they shouldn't be called on deleted instances.