-
Notifications
You must be signed in to change notification settings - Fork 291
Add RegistrarPoc id column #2761
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
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.
Reviewed 5 of 5 files at r1, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @ptkach)
db/src/main/resources/sql/flyway/V195__registrar_poc_id.sql line 23 at r1 (raw file):
ALTER TABLE "RegistrarPoc" ADD COLUMN IF NOT EXISTS id INTEGER DEFAULT nextval('"RegistrarPoc_id_seq"'::regclass);
i think we'd want to use bigserial here instead
- it creates the sequence automatically and uses it to fill, we don't manually need to create it
- has more space than an int, if we end up mucking around with the IDs later
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.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @gbrodman)
db/src/main/resources/sql/flyway/V195__registrar_poc_id.sql line 23 at r1 (raw file):
Previously, gbrodman wrote…
i think we'd want to use bigserial here instead
- it creates the sequence automatically and uses it to fill, we don't manually need to create it
- has more space than an int, if we end up mucking around with the IDs later
I'm not sure about this request - we have 1094 records currently. Even if we were to mess with 100s of records / day thus generating new values in id column it'd still take us roughly thousands of years before it fails. Are you sure we need a biserial here?
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.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @ptkach)
db/src/main/resources/sql/flyway/V195__registrar_poc_id.sql line 23 at r1 (raw file):
Previously, ptkach (Pavlo Tkach) wrote…
I'm not sure about this request - we have 1094 records currently. Even if we were to mess with 100s of records / day thus generating new values in id column it'd still take us roughly thousands of years before it fails. Are you sure we need a biserial here?
In the past we've mucked around with serial number generation so it's good to have the flexibility. And there's also (1) anyway.
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.
Reviewable status: 1 of 5 files reviewed, 1 unresolved discussion (waiting on @gbrodman)
db/src/main/resources/sql/flyway/V195__registrar_poc_id.sql line 23 at r1 (raw file):
Previously, gbrodman wrote…
In the past we've mucked around with serial number generation so it's good to have the flexibility. And there's also (1) anyway.
Updated. However I'm not convinced it's an improvement and I wouldn't consider this request a blocker for merging the pr - code lines have remained the same, it's just that postgres now creates the sequence instead of us and I still believe bigserial won't ever be required in this particular 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.
Reviewed 4 of 4 files at r2, all commit messages.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on @ptkach)
We need to have a unique id on RegistrarPoc so that we can match updates to specific records. Fixes b/421402975
This change is