WIP: Provide high-level overview of Thoth storage model #2661
Conversation
sesheta
added
do-not-merge/work-in-progress
|
Skipping CI for Draft Pull Request. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
As noted in the linked issue, maybe operationnal knowledge should not be So the current diff (only dev / internal storage logic) will be a start. |
VannTen
changed the title
sesheta
removed
the
do-not-merge/work-in-progress
| - The aforementioned results documents are referenced. | ||
| - Reference to packages sources (ex: Python packages indexes). | ||
|
|
||
| These two combined form the knowledge graph. |
There was a problem hiding this comment.
I don't know if we can summarize the content of Thoth's postgres database in such a simple way. In fact, the DB contains all kind of information not directly related to document results and package indexes, see the database model for an overview of the content available.
|
I don't know if we can summarize the content of Thoth's postgres database in such a simple way. In fact, the DB contains all kind of information not directly related to document results and package indexes, see the [database model](https://github.com/thoth-station/storages/blob/master/thoth/storages/graph/models.py) for an overview of the content available.
Can't we classify it somehow ? I had taken a (actually, some ^) look at
the models class before, and I can see there is some common patterns
between the differents models, but I'm not sure what those patterns are.
Maybe we should have more parents class regrouping related models, which
would also serve as self-documenting the code ? (by being "category" of
things stored in the DB)
|
I don't think it would be a good idea to group models under more generic objects, as declaring one class per table seems like a clearer implementation wrt SQLAlchemy ORM conventions. Do you have any examples of classes you think should be more generic to help me understand your point? |
|
Sure. For example, SoftwareEnvironment and ExternalSoftwareEnvironment EDIT: Also the various *Run (id, datetime)
Theirs docs at least suggest that inheritance is a valid way to work with the |
VannTen
changed the title
sesheta
added
the
do-not-merge/work-in-progress
Related Issues and Dependencies
closes #2658
…
Description
This intend to improve the thoth-storages modules docs to give a high-level
overview of how the data is organized, and differents items relates together.
The intended public would be :
the storage implementation
between data items: what can be recreated, at what cost, etc. + what must be
backed up atomically (avoid inconsistency)
Ideally, it should stays generic but points to part of the code / generated
documentation which can list all the concerned objects and in what "class" they
fall.
Current state
This is intended as a continuation of the conversation in #2658, so the
information might not be accurate yet, it reflects my current comprehension /
hypotheses
Goals