-
Notifications
You must be signed in to change notification settings - Fork 5
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
Generic Merge #757
Generic Merge #757
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #757 +/- ##
===========================================
+ Coverage 90.98% 91.03% +0.04%
===========================================
Files 84 84
Lines 7889 7933 +44
===========================================
+ Hits 7178 7222 +44
Misses 711 711
Continue to review full report at Codecov.
|
Sounds perfect to me, @BarisSari :-) |
migrations/sqlite_versions/2021-02-10_a382a0f4b1be_correct_privacy_id_type_of_hostedby.py
Outdated
Show resolved
Hide resolved
…c_merge # Conflicts: # .isort.cfg # requirements.txt
I'm sure I made this comment before, @BarisSari - but now I can't find it. I couldn't see this in the tests. You're testing merging entries in the |
Sure, @IanMayo. I'm extending the related test. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, thanks. Will wait for @robintw review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this @BarisSari.
The approach looks good, and I like the sqlalchemy-utils functions you're using.
I'm a little confused about a few bits though:
- Can
merge_generic
merge platforms? It doesn't look like it can at the moment - it'd be really good if all merges could just go through themerge_generic
function, so we didn't have to do platforms separately. I can see why themerge_platforms
function hasn't been deleted at the moment (as it would break the GUI), but hopefully we could delete it once I'd updated the GUI to usemerge_generic
. - What about the other metadata tables that we might want to merge? I can see the code deals with Sensor and Datafile at the moment. What about Task, HostedBy, Participant etc. @IanMayo I assume I'm correct in saying these should be able to be merged too (I know we're not using them at the moment, but it'd be good if the code supported them for when we start using them shortly).
Thanks for the review, @robintw.
|
@BarisSari - @robintw highlighted a couple of other tables that it would make sense to support merge:
|
Okay, @IanMayo. I'm modifying the PR. |
…move duplicated code from merge_platforms
…able foreign key (parent)
a265553
to
7f9f68c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @BarisSari, this looks good.
I see you've replaced most calls to merge_platforms
with merge_generic
- but there are a couple that have been missed in the tests. Could you switch those over too?
Also, given that we've now replaced all calls to merge_platforms
- I think we should be ok to delete merge_platforms
(I see you've replaced the call in the GUI too).
@@ -215,7 +218,9 @@ def test_merge_platforms_with_different_sensor_names(self): | |||
assert len(states_before_merge) == 0 | |||
assert len(contacts_before_merge) == 0 | |||
|
|||
self.store.merge_platforms([platform_2.platform_id], platform.platform_id) | |||
self.store.merge_platforms( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most of the other calls to merge_platforms seem to have been switched to merge_generic, apart from this one and a couple of others.
Okay, @robintw. I'll update the tests. But actually, I'm still calling the I just removed duplicated codes, and simplified the |
Ah yes of course @BarisSari - that makes sense. I'll approve now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All looks good now, thanks for this Baris.
🧰 Issue
Fixes #754
🔨Work carried out:
I also fixed the Sphinx error, which was causing failure: sphinx-doc/sphinx#8885
Confirmations
interactive_review
if reviewers will need to see UI\docs
folder📝 Developer Notes:
Ian suggested writing a test that merges nations, but I thought it would be better to use the most used reference table: Privacies. That's why I tested merge methods with it.
While I was working to find out the referencing foreign key fields of a table, I found
sqlalchemy-utils
. And I realised that I'm trying to reinvent the wheel. My function was almost identical to one of its helper functions. 😄 So, I also includedsqlalchemy-utils
in this PR. It has many useful functions, especially foreign key helpers: https://sqlalchemy-utils.readthedocs.io/en/latest/foreign_key_helpers.html .You might ask why I didn't use
merge_references(from_obj, to_obj)
for all merge-operations. The reason is that we should handle dependent objects(Platform-Sensor, etc.) differently. If I tried to merge two platforms that have the same sensor name, it would throw a constraint error. So, I tried to use it as much as I can (for merging reference table objects), but I didn't use it for special cases.