-
Notifications
You must be signed in to change notification settings - Fork 1k
deterministicly order journal entrys by id #3475
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
Conversation
tests/unit/forklift/test_legacy.py
Outdated
@@ -1255,7 +1255,7 @@ def storage_service_store(path, file_path, *, meta): | |||
# Ensure that all of our journal entries have been created | |||
journals = ( | |||
db_request.db.query(JournalEntry) | |||
.order_by("submitted_date") | |||
.order_by("id") |
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 wrong-ish, if someone is doing something concurrently in two different transactions, the Ids might not 100% sense although I'm not sure that this can actually ever get exposed since IIRC we're using serializable transactions. I think we'd be better off sorting first by submitted_date
, and then falling back to id
to tie break things with the same submitted_date
.
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 all the journal entries are created in the same request, they'll be created in the same transaction, so if we're using serializable transaction isolation we'll always have sequential ids.
however it is also unclear to me if this is the case, as our call to set the isolation level is inside a conditional:
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 had assumed we were set to SERIALIZABLE for all writes, so thanks for raising this.
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.
even still, the ids should be in the same order that the JournalEntry objects were added to the session, so I believe this test case is valid.
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 mean concurrent requests, so two different transactions, commiting at ~the same time. I don't know enough about PostgreSQL internals to know how it would resolve the conflict.
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.
IOW, could we get slightly different dates (because the two commits don't occur at the exact same time* with the IDs in the "wrong" order.
Previously we sorted by submitted_date, which was troublesome as many JournalEntry objects may be committed in a single transaction, leading to identical timestamps. SQLAlchemy retains the order of jounal creation, and flushes in order so ordering by id is deterministic and represents the logical order of operations. Closes #3474, thanks to @anowlcalledjosh for reporting
Previously we sorted by submitted_date, which was troublesome as many JournalEntry objects may be committed in a single transaction, leading to identical timestamps. SQLAlchemy retains the order of jounal creation, and flushes in order so ordering by submitted_date, id is deterministic and represents the logical order of operations. Closes pypi#3474, thanks to @anowlcalledjosh for reporting
Previously we sorted by submitted_date, which was troublesome as many JournalEntry objects may be committed in a single transaction, leading to identical timestamps.
SQLAlchemy retains the order of jounal creation, and flushes in order so ordering by id is deterministic and represents the logical order of operations.
Closes #3474, thanks to @anowlcalledjosh for reporting