feat(PM-3404): add phone number to member profile #24
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| @@ -0,0 +1,19 @@ | |||
| -- CreateTable | |||
| CREATE TABLE "members"."memberPhone" ( | |||
| "id" TEXT NOT NULL, | |||
There was a problem hiding this comment.
[design]
Consider using a UUID type for the id column instead of TEXT to ensure uniqueness and improve performance when generating IDs.
| "id" TEXT NOT NULL, | ||
| "userId" BIGINT NOT NULL, | ||
| "type" TEXT NOT NULL, | ||
| "number" TEXT NOT NULL, |
There was a problem hiding this comment.
[correctness]
Storing phone numbers as TEXT can lead to inconsistencies. Consider using a more structured format or validation to ensure phone numbers are stored in a consistent manner.
| CREATE INDEX "memberPhone_userId_idx" ON "members"."memberPhone"("userId"); | ||
|
|
||
| -- AddForeignKey | ||
| ALTER TABLE "members"."memberPhone" ADD CONSTRAINT "memberPhone_userId_fkey" FOREIGN KEY ("userId") REFERENCES "members"."member"("userId") ON DELETE CASCADE ON UPDATE CASCADE; |
There was a problem hiding this comment.
[performance]
Ensure that the userId in the member table is indexed to optimize the performance of the foreign key constraint.
| model memberPhone { | ||
| id String @id @default(uuid()) | ||
| userId BigInt | ||
| type String |
There was a problem hiding this comment.
[maintainability]
Consider using an enum for the type field to ensure consistency and prevent invalid values. This can improve data integrity and make the codebase more maintainable.
| id String @id @default(uuid()) | ||
| userId BigInt | ||
| type String | ||
| number String |
There was a problem hiding this comment.
[❗❗ correctness]
The number field should be validated to ensure it contains a valid phone number format. Consider adding constraints or using a library to enforce this.
| member member @relation(fields: [userId], references: [userId], onDelete: Cascade) | ||
| createdAt DateTime @default(now()) | ||
| createdBy String |
There was a problem hiding this comment.
[💡 design]
The createdBy field is non-nullable, which might cause issues if the creator's information is not available at the time of record creation. Consider making this field nullable if there's a possibility of missing data.
| data.newEmailVerifyToken = uuid() | ||
| data.newEmailVerifyTokenDate = new Date(new Date().getTime() + Number(config.VERIFY_TOKEN_EXPIRATION) * 60000).toISOString() | ||
| } | ||
| const phoneRegex = /^\+[1-9]\d{1,14}$/ |
There was a problem hiding this comment.
[💡 performance]
Consider moving the phoneRegex definition outside of the updateMember function to avoid redefining it on every function call. This can improve performance slightly and enhance maintainability by keeping constants at the top of the file.
| // clear addresses so it doesn't affect prisma.udpate | ||
| delete data.addresses | ||
|
|
||
| const phonesWereUpdated = data.phones !== undefined |
There was a problem hiding this comment.
[performance]
The logic for updating phone numbers involves deleting all existing phone records and then re-creating them if data.phones is provided. This approach can be inefficient and may lead to data loss if an error occurs between deletion and creation. Consider updating only the changed phone records to improve performance and reliability.
What's in this PR?
Ticket link - https://topcoder.atlassian.net/browse/PM-3404