-
Notifications
You must be signed in to change notification settings - Fork 3
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
Implement PublishIdentityUpdate and GetInboxLogs endpoints #377
Conversation
} | ||
|
||
// TODO: Implement serializable isolation level once supported | ||
if err := s.db.RunInTx(ctx, &sql.TxOptions{ /*Isolation: sql.LevelSerializable*/ }, func(ctx context.Context, tx bun.Tx) error { |
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.
Why is every tool for working with SQL in Go so terrible?
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 hate Bun. I hate Gorm. Sqlx is fine but very bare-bones.
I've heard good things about sqlc
but never tried 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.
Awesome, this will be a good list to try when we come back to this. Always hate working with ORM's
for i, req := range reqs { | ||
inbox_log_entries := make([]*InboxLogEntry, 0) | ||
|
||
err := s.db.NewSelect(). |
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 be nice to get all of these in a single SQL query, but we can optimize that later.
Stubbed out the validation service for now, as well as the
GetInboxIds
endpoint - these will be implemented in the next PR. Also will add more efficient InboxID encoding, and idempotent publishes, shortly.Notes:
I did not split the logic between 'store' and 'service' layers. It seems 90% of the logic would be in the database anyway, and it felt like splitting it up would make it harder to optimize later. Happy to refactor if anyone disagrees though.
Our ORM Bun does not currently support custom isolation levels for Postgres. Decided to punt this for now - using SERIALIZABLE isolation level just prevents races when two
CreateInbox
updates are published simultaneously, which should be mostly prevented by our hash validation mechanism anyway.