Skip to content

immutability / deprecation proposal #203

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jdcourcol wants to merge 2 commits into
base: main
Choose a base branch
from
Open

immutability / deprecation proposal #203

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
8ad5926
immutability / deprecation proposal
May 27, 2025
2dbf13f
Mike's feedback
May 28, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 20 additions & 4 deletions docs/schema.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -107,7 +107,23 @@ Can be controlled by an agent or occur automatically.
We may need to know who did what modification on entities. However, we don't have to store that information the same way as the latest version of the entities as we won't perform queries on previous state of the entity.
We may store for instance, in some system/table, an entry with: entity_id, date, who, entity_serialized_as_json.
We can initially start w/o auditing





- **Immutability**:

Properties changing the fundamental identity of the entity should be marked as immutable (TBD: how technically) and cannot be assigned outside of the creation of the entity.
Copy link
Contributor

@eleftherioszisis eleftherioszisis May 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would there be the possibility we would need to fix an immutable property?

Copy link
Contributor Author

@jdcourcol jdcourcol Jun 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say no. We will see if that case actually happens when we cross that bridge.


The remaining properties are considered `non-fundamental`; that is, they do not alter the fundamental identity or semantic role of the entity.

For instance:
- memodel and calibration values. As different calibration values mean a different behaviour of the memodel, we store the memodel in one entity and the calibration values in another entity. The combination of the 2 entities defines the behaviour of the memodel.
- description, name are not changing the fundamental identity of an entity.

- **Deletion**:
- Entities can be deleted except if they are referenced by other entities.
Copy link
Collaborator

@GianlucaFicarelli GianlucaFicarelli Jun 2, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it desired/acceptable:

  • to hard delete the unreferenced entities (i.e. remove them from the db)
  • to hard delete any referenced asset (i.e. remove them from the db and S3)

Copy link
Collaborator

@mgeplf mgeplf Jun 2, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, does "delete" just actually delete the row, are are we doing the "normal" having a column deleleted that gets marked true? We may need both, to comply w/ right to be forgotten.

Copy link
Contributor Author

@jdcourcol jdcourcol Jun 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, I would give the possibility to delete any unreferenced entities and assets. (no column deleted)


- **Deprecation**:
- Entity can marked as deprecated.
- Deprecated entities would be ignored from queries except if explicitly asked for.