-
Notifications
You must be signed in to change notification settings - Fork 58
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
refactor(sqlite): move migrations logic to sqlite common module #1325
Conversation
92aac88
to
194f51c
Compare
Jenkins BuildsClick to see older builds (2)
|
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.
LGTM!
194f51c
to
475839c
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.
LGTM
@@ -1,334 +1,7 @@ | |||
{.push raises: [Defect].} | |||
{.push raises: [].} |
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 starting to add these. Can you see any (good) reason for us to rather use:
when (NimMajor, NimMinor) < (1, 4):
{.push raises: [Defect].}
else:
{.push raises: [].}
?
Perhaps if someone compiles nwaku into a system with an older nim version (unlikely and should probably not be allowed) or (perhaps more likely) that the nimbus-build-system gets downgraded due to some unforeseen issues?
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.
I removed the Defect
because the compiler added extra noise because of that pragma. I did it as an experiment, and I forgot to restore it.
Perhaps if someone compiles nwaku into a system with an older nim version (unlikely and should probably not be allowed) or (perhaps more likely) that the nimbus-build-system gets downgraded due to some unforeseen issues?
Absolutely! Let's do this in a unique PR where we change all the occurrences. WDYT? 🤔
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.
Yeah, absolutely. This can be merged as is IMO. For me there is the more general questions on why we would want to keep the modules compatible with Nim <1.4, but that is a separate discussion and cost is low in any case.
As an intermediate step, I decided to do a minor cleanup before we take another decision about what to do with the SQLite migrations. I moved the logic to the
waku/common
module where SQLite database code was moved previously.common/sqlite
module since this code is agnostic to any implementation.