Soft deleted referenced entries are still returned

When I soft-delete an entry, save the changes and then load another entity that has a one-to-many relationship with the deleted one, the deleted entry is still returned but with the "DeletedOn" attribute set. If I dispose the context and create a new one after saving changes, the deleted entry is no longer returned, which is correct.

This produces the wrong behavior:

        unitOfWork.Remove(position);
        unitOfWork.SaveChanges();

        var docFromDb = unitOfWork.FindById<Document>(document.Id);
        Assert.IsTrue(docFromDb.Positions.Any() == false); // Position is still in the list, with DeletedOn set;

This produces the correct behavior:

        unitOfWork.Remove(position);
        unitOfWork.SaveChanges();
        unitOfWork.Dispose();
        unitOfWork = new DatabaseContext(connectionString, 1).GetUnitOfWork();

        var docFromDb = unitOfWork.FindById<Document>(document.Id);
        Assert.IsTrue(docFromDb.Positions.Any() == false); // Position is not in the list

I don't think that disposing the UnitOfWork after every SaveChanges is a possible solution. I would consider this a bug. Or is this expected behavior?

Thanks, Sebastian

Hi Sebastian,

It is expected. The reason here is that the UnitOfWork contains it's own cache, so the entity is still within the active unit of work and therefore is flagged as deleted.

When you run the query (FindById) directly on the UnitOfWork, then you're querying it's cache.

Most of the time you'll be wanting to use a unit of work in a using block, so it's short lived and therefore would remove the entity and then itself be discarded. The cost of this is low, because of connection pooling etc and it also keeps memory utilization down.

I hope that helps!

John-Daniel Trask

Hi John-Daniel and thanks for the quick reply.

Since we're porting a large application to Lightspeed, the queries all exist already. They don't create and use the Lightspeed UnitOfWork directly but through several wrappers and repositories. Is there another way to achieve the behavior I want? Shouldn't Lightspeed's cache also adhere to the same policy?

Thanks, Sebastian

Hi Sebastian,

No, you need to use the unit of work pattern in the manner it was designed. By not completing it, you're suggesting the unit of work is still in progress, and as you're using soft deletes, you may still be using those entities. You're explicitly asking for an entity of that ID directly from the LightSpeed unit of work cache - and it does know the entity exists, because it's been in the current scope of work - which is why it is found, but with the deleted flag set.

Even if it made sense to make this change, it would be a breaking API change for the thousands of organisations that already use LightSpeed.

I'd recommend refactoring your abstractions to respect the design patterns that LightSpeed uses. Without that you'll likely run into several other issues down the road around caching, memory utilization, connectivity, etc.

Kind regards,

John-Daniel Trask

Hi John-Daniel and thanks for the detailed explanation.

To clarify, I am not asking for the deleted entity via its Id but it is loaded through a collection. I tried re-creating the UnitOfWork after every SaveChanges, but that lead to many exceptions stating that the context is already disposed.

To work around this problem, I came up with the idea to modify the template. I managed to generate code that handles this like this:

$Translator.TranslateMethodAttributes($relationship.PropertyAttributes) IQueryable<$Translator.QualifiedTypeName($relationship.To)> $relationship.Name
{
  get { return Get(_$Inflector.CamelCaseCollection($relationship)).Where(e => e.DeletedOn.HasValue == false).AsQueryable(); }

I added the DeletedOn query to every collection. Do you think this is a viable option or are there side-effects when generating the query?

Thanks, Sebastian

Hi Sebastian,

Sorry about the delay in replying. Appreciate the clarification that it's still coming through in collections.

As for the fastest work around, your code looks like it would do the job well :-)

Kind regards,

John-Daniel Trask