-
Notifications
You must be signed in to change notification settings - Fork 0
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.
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
Database organization #34
Comments
In GitLab by @mcastril on Oct 24, 2023, 13:29 Thank you for creating the issue @LuiggiTenorioK. I can delete it now from my to-do list. Hopefully we won't have to write most of the API again, I hope so. As discussed today, before we had the distributed DDBB scheme (DDBBs for every experiment) Autosubmit API only relied on the central For that reason, many API operations may use In Autosubmit4, we wanted to remove legacy tables as Related issue: https://earth.bsc.es/gitlab/es/autosubmit/-/issues/858 However, it's important to keep compatibility with AS3 by now. |
In GitLab by @mcastril on Oct 24, 2023, 13:32 The DDBBs documentation, which didn't make it into de wiki yet because I think that it still needs more information could give you some hints and could also benefit a lot from your analysis. We can use it as a baseline to have complete documentation. As you say, we must know, for every DDBBs, who is the writers and consumers, and if possible from which version (but I understand the difficulty of this). It's also important to realize the status of the current DDBBs. Which experiments have corrupted instances and so. The fix can come by the Related issue: https://earth.bsc.es/gitlab/es/autosubmit/-/issues/1018 |
In GitLab by @mcastril on Oct 24, 2023, 13:33 Other related issues: https://earth.bsc.es/gitlab/es/autosubmit/-/issues/1054 https://earth.bsc.es/gitlab/es/autosubmit/-/issues/1007 |
I also hope that we don't have to write the API again. But, I'll keep in mind which tables the API is responsible for, and design a code architecture that layers the API logic from the database structure. Probably not by changing everything at once but mostly for new features and modifications. That's why is at least required to separate these data responsibilities accurately among our projects. |
Some notes about the tables:
|
In GitLab by @mcastril on Jan 4, 2024, 10:02 @LuiggiTenorioK it would be quite helpful that you update the DDBB documentation GDoc while you take your notes (with track changes) to get a better understanding of these details within the team |
Yes, I will look into how can we document it effectively because I'm not sure if a GDoc is the best place to do it. Also because the developer guide GDoc was deleted recently (but I did a backup before it was removed). |
In GitLab by @mcastril on Jan 5, 2024, 12:52
The GDoc was a medium for drafting purposes, as it enables commenting, tracking changes and online collaboration. The final purpose was to upload it somewhere else. A summary got into the final Autosubmit documentation and we haven't decide yet where to publish the full doc. In your case, for doing amendments and additions I think GDoc is the best place (using track changes) because it will help us to know about your findings and discuss about them.
Thanks for saving it Luiggi. We should also publish it somewhere (maybe rephrasing some sections). I could ask Cristian anyway because I am in contact with him. |
@mcastril @kinow @dbeltrankyl I made a copy of the DDBB Gdoc to update it with the information of the databases to have a better view of the data available there (and to not lose the document as the previous one). Here is the new document: Also, here is the developer guide that I backed up: |
mentioned in issue autosubmit#1210 |
I realized that, in order to make the API portable, We need to map which tables are granted to exist and be maintained for every supported version of autosubmit (maybe >= 3.13?).
Going back to issue #22, we have a complete picture of all the tables and databases that exist in our production environment. Unfortunately, it seems that some of them were created or modified manually by a script to make some features work. This will lead to potential bugs when deploying the API to new environments as some data may be missing or deprecated for different versions of autosubmit.
I think that a good work path is to map what tables are from the autosubmit package (the versions we are going to support) in a clear way, and then define what is the minimal amount of tables that the API needs to extend to work properly. In this way, we can also deprecate the
as_times.db
and have one central db.This work may lead to a huge refactoring of the code (maybe making it feasible to write most of the API again), but I think it will take less time than solving the further issues generated by not doing it. Also, that in the way we can solve other issues like API-side data validation.
New DDBB documentation Google Doc 📎
@kinow @dbeltrankyl @mcastril
The text was updated successfully, but these errors were encountered: