Datasource for all elements about carsus

[mishinma]

The idea there was that quantities are related to one line or level that already have a datasource. Therefore, the datasource for the quantities can be obtained by joining them on the levels/lines table. Another way could be to add the datasource field to QuantityMixin and then all quantities would have it. But then levels and lines also have a datasource and IMO that is bad.

Relevant scheme:
https://trello-attachments.s3.amazonaws.com/5720fd4f7dc76ef0c90c43c5/1115x599/b3a9c949603806aeb5ec7075b63716cc/pr_transition_mapping_classes.png

[yeganer]

That's a point I can understand.
My idea was to make it easier to purge all data connected to one datasource from the database.

The current model does not allow updating data inside the database and ingesting new data will at some point corrupt the database if for example a level is ingested twice.

So in the long run, if we don't want to rebuild the database every time, we need a mechanism to easily update data or make it easy to remove all data linked to one datasource.

[mishinma]

From database design point of view I think it would be really beneficial to abstract levels and transitions (like atoms and ions) based on some inherent properties. Then Quantities could have the datasource field, as they are measured and therefore are not absolute. But it turned out to be a very nontrivial task, so I added datasource to levels and transitions themselves.

Thinking about it again now, I agree that adding datasource to quantities is a good idea. We just need to have a rule (maybe implicit and not enforced) that a level and its related quantities must come from the same datasource. I also think we should not allow to ingest a level from the same datasource twice (maybe as a constraint). No constraints are enforced presently.