Skip to content
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: change primary key of verifiable and recovery addresses #4138

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

alnr
Copy link
Contributor

@alnr alnr commented Oct 2, 2024

This changes improves lookup performance for verifiable and recovery addresses.

Please be aware that this primary key change may require exclusive locks in your database. Test your upgrade before applying it in production.

@alnr alnr self-assigned this Oct 2, 2024
Copy link

codecov bot commented Oct 2, 2024

Codecov Report

Attention: Patch coverage is 91.17647% with 3 lines in your changes missing coverage. Please review.

Project coverage is 78.58%. Comparing base (629d867) to head (792cee3).
Report is 4 commits behind head on master.

Files with missing lines Patch % Lines
driver/registry.go 0.00% 3 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #4138      +/-   ##
==========================================
- Coverage   78.61%   78.58%   -0.04%     
==========================================
  Files         378      380       +2     
  Lines       26936    27013      +77     
==========================================
+ Hits        21177    21228      +51     
- Misses       4147     4172      +25     
- Partials     1612     1613       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@aeneasr aeneasr changed the title feat: change primary key on identity_verifiable_addresses and identit… refactor: change primary key of verifiable and recovery addresses Oct 3, 2024
@@ -0,0 +1,7 @@
ALTER TABLE identity_verifiable_addresses
DROP FOREIGN KEY identity_verifiable_addresses_ibfk_1;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we need this because the primary key won't be deleted if there is still a foreign key using it, correct?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

exactly.

Comment on lines +3 to +7
ALTER TABLE identity_verification_codes
DROP CONSTRAINT identity_verification_codes_identity_verifiable_addresses_id_fk;

ALTER TABLE identity_verification_tokens
DROP CONSTRAINT identity_verification_tokens_identity_verifiable_address_i_fkey;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do these need to be dropped and recreated?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes:

ERROR: cannot drop constraint identity_recovery_addresses_pkey on table identity_recovery_addresses because other objects depend on it (SQLSTATE 2BP01)

@@ -0,0 +1,3 @@
ALTER TABLE identity_verifiable_addresses
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this missing a unique index for id?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure, can you explain why we need that unique index? If there is any FK to this table, that should always use the PK and not just the id column.

Comment on lines +1 to +7
ALTER TABLE identity_recovery_codes
DROP FOREIGN KEY identity_recovery_codes_identity_recovery_addresses_id_fk,
DROP FOREIGN KEY identity_recovery_codes_identity_id_fk;

ALTER TABLE identity_recovery_tokens
DROP FOREIGN KEY identity_recovery_tokens_identity_id_fk,
DROP FOREIGN KEY identity_recovery_tokens_identity_recovery_addresses_id_fk;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to remove/recreate the child's foreign key if we change a constraint in the other table?

Copy link
Contributor Author

@alnr alnr Oct 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This dance is only necessary on MySQL.

In this particular case, yes.

@alnr alnr force-pushed the alnr/addresses-pk branch from 803208b to ca35cfb Compare October 7, 2024 13:45
Copy link
Member

@zepatrik zepatrik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that the FKs should also become composite, so we don't need an additional unique index that serves no real purpose.

@@ -0,0 +1,3 @@
ALTER TABLE identity_verifiable_addresses
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure, can you explain why we need that unique index? If there is any FK to this table, that should always use the PK and not just the id column.

Comment on lines +13 to +17
ALTER TABLE identity_verification_codes
ADD CONSTRAINT identity_verification_codes_identity_verifiable_addresses_id_fk FOREIGN KEY (identity_verifiable_address_id) REFERENCES identity_verifiable_addresses(id) ON DELETE CASCADE;

ALTER TABLE identity_verification_tokens
ADD CONSTRAINT identity_verification_tokens_identity_verifiable_address_i_fkey FOREIGN KEY (identity_verifiable_address_id) REFERENCES identity_verifiable_addresses(id) ON DELETE CASCADE;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As the PK changed, the foreign key should also change.

Suggested change
ALTER TABLE identity_verification_codes
ADD CONSTRAINT identity_verification_codes_identity_verifiable_addresses_id_fk FOREIGN KEY (identity_verifiable_address_id) REFERENCES identity_verifiable_addresses(id) ON DELETE CASCADE;
ALTER TABLE identity_verification_tokens
ADD CONSTRAINT identity_verification_tokens_identity_verifiable_address_i_fkey FOREIGN KEY (identity_verifiable_address_id) REFERENCES identity_verifiable_addresses(id) ON DELETE CASCADE;
ALTER TABLE identity_verification_codes
ADD CONSTRAINT identity_verification_codes_identity_verifiable_addresses_id_fk FOREIGN KEY (identity_verifiable_address_id) REFERENCES identity_verifiable_addresses(identity_id, id) ON DELETE CASCADE;
ALTER TABLE identity_verification_tokens
ADD CONSTRAINT identity_verification_tokens_identity_verifiable_address_i_fkey FOREIGN KEY (identity_verifiable_address_id) REFERENCES identity_verifiable_addresses(identity_id, id) ON DELETE CASCADE;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants