| Page Properties | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Overrides/Supersedes
...
Rationale
Analysis and options
Basically, 2 main alternatives can be suggested for the provided context:
Alternative option | Brief description | Potential use cases |
|---|---|---|
| Cascade deletion | deleting a code-module record leads to all non-core-modules records referring to it must also be deleted |
|
| Soft deletion | a core-module record is not being physically deleted but is being rather marked with a specific dedicated flag (e.g. is_deleted = true / false) |
|
It looks that both options can be viable for FOLIO depending on particular use case.
It worth also noting that 
UICR-125 - Data corruption. When holding/item data are moved in Inventory, then the item in Courses is not updated accordingly OPENcase is slightly different and is about dangling references while not deletion but moving of a core-module record; neither cascade nor soft deletion is applicable here. At the same time, this case and cascade deletion case have one great similarity - in both, non-core-modules are to be notified about a change in core-module. In this context, a robust notification channel with guaranteed delivery to transfer change events from one module (say, module-source) to another module (say, module-recipient) is required. More details are on Data consistency and message driven approach # Notification channel.
Soft deletion option
More details regarding this option.
- Q: It requires that every client understands that deleted records might be present and when the API will provide them and when it will not.
- A: Sure, every client should know the rules of the game. Though once the rules will be agreed and shared, it's just a platform-wide knowledge
- Q: Let's say a loan references an item, that item is then soft-deleted, when the loan is presented in the UI, would the item information be presented or not?
- A: Yes, the loan is available, and the item information still can be retrieved by a single endpoint. At the same time, loan UI should be able to notify end user that the item has been deleted (via a warning message, or via a dedicated UI field, or via disabling of editing particular values received from the item
High level actions required for core / non-core modules are shown below:
Core module | Another module referencing core module |
|---|---|
|
|
Decision
Yikes
Implications
...