Soft Deletes

[jeremydmiller]

If a document type is so marked, treat deletions of that document as a "soft delete." Maybe have:

var store = DocumentStore(_ => {
    _.For<User>().SoftDeletes();


});

That would force Marten to add an additional column to the storage table for "deleted" and make that false by default. We would then need to intercept deletion requests and do it instead by marking the "deleted" column to true.

The DocumentMapping default query filtering would then need to set deleted = false so that normal calls to session.Query<User>() would automatically filter out soft deleted documents.

Come back with an explicit "session.Query().IncludeDeleted()" that would get you out of the deletions.

[CodingGorilla]

Come back with an explicit "session.Query().IncludeDeleted()" that would get you out of the deletions.

The .IncludeDelete() implies that this will return documents that have and have not been soft deleted, right? So then would there also be a: session.Query().OnlyDeleted()?

[jeremydmiller]

Bad phrasing on my part. So how about:

IncludeDeleted() gets you all documents regardless of deletion status, and OnlyDeleted() does exactly what it sounds like?

[headdetect]

Would it be beneficial to have the deleted column be a DateTime so you can see when it was deleted?
For example, deleted_at would be null if not deleted yet, or it would have the time it was deleted at if deleted.

[jeremydmiller]

@headdetect Hadn't thought about that, but yeah, we'll do that.

[jeremydmiller]

Tasking for this -- but this is only a preliminary guess jotted down just to give @nieve a head start if he still wants to do it;)

• DocumentMapping.DeletionStyle = Remove/SoftDelete
• `StoreOptions.Schema.For().SoftDeletes()
• [SoftDelete] attribute as an alternative
• If soft deleted, DocumentMapping needs to add a "deleted" field
• DocumentMapping.FilterDocuments() will need to add something for "deleted = false"
• IQueryableDocument.FilterDocuments() probably needs to take in the QueryModel so it could search
  for result operators to "know" how to create the filter
• Linq support for IncludeDeleted(), including the compiled query
• Linq support for DeletedOnly(), including the compiled query
• Test that the patch generation for adding the soft delete option to an existing table
• Have to change the UpdateBatch mechanics for deletions. One way or another, the deletion has to be done by bouncing through IDocumentStorage for the document type to "know" how to add the right ICall for deletion

[nieve]

Great stuff, will get cracking 😄
One thing though- the "deleted" field, shouldn't it be deleted_at (nullable DateTime, null by default) as mentioned above?

[jeremydmiller]

@nieve I was thinking two fields, but yeah, deleted_at as a nullable field is probably easier. Another thing I've kicked around on paper is creating a new concept of an IDeleter<T> that only governs creating the SQL for doing both the delete by Id and delete by where clause. I'm seeing 4 permutations of it:

1. Normal removals
2. Soft deletes
3. Subclass normal removals
4. Hierarchical soft deletes

Maybe we could build out those four flavors of IDeleter, and have it determined just once per doc type and used throughout?