-
Notifications
You must be signed in to change notification settings - Fork 53
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
feat(postgresql): align Andrea's PR#1590 changes into master #1764
Conversation
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.
Afaict this looks good. I imagine a tricky step will be integrating this with configuration and the rest of the node :)
method sleep*(s: PostgresDriver, seconds: int): | ||
Future[ArchiveDriverResult[void]] {.base, async.} = |
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.
If this is not overridden/inherited anywhere else, it should not be annotated base
and be a proc
rather than a method
.
@@ -19,6 +19,10 @@ import | |||
./v2/waku_archive/test_retention_policy, | |||
./v2/waku_archive/test_waku_archive | |||
|
|||
# TODO: add the postgres test when we can mock the database. |
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.
In case you wanted to have tests enabled in CI, you could just exec a docker run
command from tests to setup DB prior execution the tests themselves - it should work fine in CI
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.
Hey @vpavlin ! In the end I will tackle that in a separate PR because I need to tweak it in a way that the postgres tests are only run on a Linux platform. This is because the GH Actions only allow starting a docker container within Linux runners.
Thanks for the hint !
|
||
import ./postgres_driver/postgres_driver | ||
|
||
export postgres_driver |
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.
missing new line:) Would you like to add it?
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! thanks! left a comment that might be important, let me know otherwise :)
");" | ||
|
||
proc insertRow(): string = | ||
"""INSERT INTO messages (id, storedAt, contentTopic, payload, pubsubTopic, |
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.
will this insert work if we try to insert a duplicated message? I mean, insert a message twice. Perhaps we need ON CONFLICT?
mind adding a testcase if its the case?
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 the comment @alrevuelta
I think it should be added correctly as the primary key would be different, given different timestamps (nanosecconds precision)
The expected behavior is that the duplicate messages are properly added right ?
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 think this is a good point. True duplicate messages (i.e. the exact same message from the same source with same timestamp) should not be inserted twice. I think it will correctly fail because of the resulting primary key clash, but since we plan to have multiple store nodes all write to the same (shared) postgresql instance many duplicates will be expected. May be worth understanding how reliably (and quickly) this "expected failure on duplicate" works.
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.
In case of completely equal messages, the put
call will return an error. I will add a little test with the next:
putRes = await driver.put(DefaultPubsubTopic,
msg2, computeDigest(msg2), msg2.timestamp)
## Then
require:
not putRes.isOk()
try: | ||
let res = s.connection.tryExec(sql(createTableQuery())) | ||
if not res: | ||
return err("failed to migrate database") |
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.
would an error saying failed to initialize
make more sense here? Or is this a prep for adding migrations in the future?
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.
You are absolutely right! I'll set a that more meaningful error message straightaway.
for r in rows: | ||
let rowRes = extractRow(r) | ||
if rowRes.isErr(): | ||
return err("failed to extract row") |
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.
Will this also print/pass the actual error from extractRow
?
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.
Good catch! I'll add it :)
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.
Few questions/comments mainly to feed my curiosity:) Otherwise, LGTM!
proc dropTableQuery(): string = | ||
"DROP TABLE messages" | ||
|
||
proc createTableQuery(): string = |
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.
Curious if we can manage migrations in plain SQL, so that other implementations can use the same migrations (not a blocker, just want to know your thoughts)
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.
Good point @rymnc ! I'll set that as a pending action item in the issue
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.
Code looks good to me, I won't approve since I have co-written it, thank you @Ivansete-status for taking care of it!!
90b5549
to
3bc28fb
Compare
3bc28fb
to
8e4be4e
Compare
Special kudos to @cammellos for submiting the original PR! If you consider that we are missing any important change we can create a separate issue to tackle it. |
Summary
This PR is aimed to align the great progress made by @cammellos in terms of PostgreSQL adoption, into our
master
branch. With this, we add apostres
driver that allows to interact with a PostgreSQL database.Details
The important changes were introduced in the next PR.
#1590
Apart from the adaptation I add a tiny test aimed to explicitly test the asynchronicity, which should work once we add the Lorenzo's changes.
My idea was to align Andrea's branch first and then work on the PR#1590 but I rebased it from
origin/master
as ususal so I need to merge intomaster
. Sorry for that Andrea.How to test it
Pending tasks
postgresql
driver to cover all the "archive" features.Issue
#1604