Commit 3d1ad6b
committed
Ensure that null values are removed entirely
Previously, when a null value was submitted to `SetValue()`, it would simply overwrite the `TrackedRecord<T>.Value` with `null`, but keep the record in place. That is confusing when e.g. calling `Remove()`, and can lead to bugs when relying on e.g. `Contains()`, as records will exist for values that have effectively been deleted. Since we already track these deleted records via `DeletedItems`, it makes more sense to actually remove them.
To facilitate this, the null check now explicitly calls `Remove()` instead of falling back to persisting the `TrackedRecord<T>` with the null `Value`.
As part of that, I refactored how null values are handled when an existing record doesn't exist; in that case, the method returns quickly, thus preventing the need to check for null `updatedItem` values, or worrying about the `enforceBusinessLogic` being inappropriately disabled.
This satisfies the first portion of #79 by ensuring that `SetValue()` actually removes the record. In subsequent commits, I will ensure that `Remove()` and `Clear()` properly enforce business logic.1 parent 7df6472 commit 3d1ad6b
1 file changed
Lines changed: 5 additions & 4 deletions
Lines changed: 5 additions & 4 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
472 | 472 | | |
473 | 473 | | |
474 | 474 | | |
475 | | - | |
476 | | - | |
| 475 | + | |
| 476 | + | |
477 | 477 | | |
478 | 478 | | |
| 479 | + | |
479 | 480 | | |
480 | 481 | | |
481 | 482 | | |
| |||
507 | 508 | | |
508 | 509 | | |
509 | 510 | | |
510 | | - | |
511 | | - | |
| 511 | + | |
| 512 | + | |
512 | 513 | | |
513 | 514 | | |
514 | 515 | | |
| |||
0 commit comments