Skip to content
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

Support schema 300 (settings) #366

Merged
merged 63 commits into from
May 22, 2024
Merged

Conversation

margrietpalm
Copy link
Contributor

@margrietpalm margrietpalm commented Mar 18, 2024

Should be used with latest schema, currently on margriet_46_schema_300!

Apologies for the large number of changes. Most changes just involve rename tables and or columns. But due to the changes in the schema, some checks have been modified, removed or added. Please see the comments I made in this PR for some extra context.

In this updated version the settings tables, except AggregationSettings, have exactly one row. The migration takes care of enforcing this and retaining the correct settings. Previously, filters for the first row of GlobalSetting and matching setting table rows were created and the checks were only performed on that data. This machinery has been removed because there should be only one row.

The integration tests ensure that the results of the model checker are unchanged, except for expected results due to the schema changes.

pyproject.toml Outdated Show resolved Hide resolved
@margrietpalm margrietpalm requested review from elisalle and jpprins1 and removed request for jpprins1 and elisalle April 8, 2024 08:13
Copy link
Contributor

@caspervdw caspervdw left a comment

Choose a reason for hiding this comment

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

Wat een werk! Dit is wel iets waar klanten direct baat bij hebben als het goed zit. Ik heb een paar dingen aangetekend, niets groots, kijk er even naar.

Met name het "join" probleem dat is geintroduceerd door de xpliciete foreign keys tussen de settings tabellen weg te halen.

Het lijkt me prima als je overal een "cartesian" join doet, wat betekent dat alle combinaties van records tussen tabel A en B worden gemaakt. Alleen sqlalchemy geeft daar een waarschuwing voor. Zie mijn comments om daar omheen te werken.

threedi_modelchecker/checks/other.py Outdated Show resolved Hide resolved
threedi_modelchecker/checks/other.py Show resolved Hide resolved
threedi_modelchecker/checks/other.py Outdated Show resolved Hide resolved
threedi_modelchecker/checks/other.py Outdated Show resolved Hide resolved
threedi_modelchecker/config.py Outdated Show resolved Hide resolved
threedi_modelchecker/config.py Outdated Show resolved Hide resolved
threedi_modelchecker/config.py Outdated Show resolved Hide resolved
threedi_modelchecker/config.py Show resolved Hide resolved
threedi_modelchecker/config.py Outdated Show resolved Hide resolved
threedi_modelchecker/config.py Outdated Show resolved Hide resolved
@elisalle elisalle removed their request for review April 8, 2024 08:57
@caspervdw caspervdw self-requested a review May 22, 2024 09:17
@margrietpalm margrietpalm merged commit 79ff24c into master May 22, 2024
6 checks passed
@margrietpalm margrietpalm deleted the margriet_363_schema_300_settings_v2 branch May 22, 2024 13:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants