[Client Profiles] HRM Migrations and save automation #469
Conversation
…given contact number (identifier)
hrm-domain/hrm-service/migrations/20230926214506-create-client-profiles-tables.js
Outdated
Show resolved
Hide resolved
hrm-domain/hrm-service/migrations/20230926214506-create-client-profiles-tables.js
Show resolved
Hide resolved
hrm-domain/hrm-service/migrations/20230926214506-create-client-profiles-tables.js
Show resolved
Hide resolved
hrm-domain/hrm-service/migrations/20230926214506-create-client-profiles-tables.js
Outdated
Show resolved
Hide resolved
hrm-domain/hrm-service/src/client-profile/sql/client-profile-insert-sql.ts
Outdated
Show resolved
Hide resolved
GPaoloni
changed the title
|
Is the intention for ProfileFlags to always be a predefined list managed from the HRM codebase, or is it the intention to have user definable flags in the future? I ask because if a lookup table is a predefined set of values that only changes if the application is updated, I prefer to key them on a human readable string 'code' rather than an integer or UUID, it can save lots of time debugging in the future! |
| console.log("Table 'Identifiers' ownership altered."); | ||
| await queryInterface.sequelize.query(` | ||
| CREATE INDEX IF NOT EXISTS "Identifiers_identifier_accountSid" ON public."Identifiers" USING btree | ||
| ("identifier" ASC NULLS LAST, "accountSid" COLLATE pg_catalog."default" ASC NULLS LAST) |
There was a problem hiding this comment.
Do we want this table to permit duplicate identifiers for the same account or should we add a unique constraint to this index?
| accountSid: string, | ||
| ): Promise<TResult<{ identifier: Identifier; profile: Profile }>> => { | ||
| try { | ||
| if (!idx) { |
There was a problem hiding this comment.
Do we care about the get / create logic being atomic? At the moment, with no unique constraint being enforced there's a small chance we could duplicate identifiers here
| @@ -267,6 +268,18 @@ export const createContact = async ( | |||
| conversationMediaPayload, | |||
| } = getNewContactPayload(newContact); | |||
|
|
|||
| const profileResult = await getOrCreateProfileWithIdentifier(conn)( | |||
There was a problem hiding this comment.
Absolutely fine for now but I wonder in the future if profile creation should be tied to contact creation? We've separated transcript creation now, and in the future profiles might be auto-generated on the back end?
There is also the case of offline contacts, presumably those will have their identifier added manually by the counsellor after they are created, so will need to be linked up after the fact.
I know this is all out of scope for this PR and this totally makes sense for now, just thinking aloud
There was a problem hiding this comment.
The initial work is basically to get to feature parity with the current "previous contacts" banner, but using robust backend systems that will allow for expansion. Profile creation will definitely not be tied one to one like this with contact creation in the future... exactly what it will look like is a bit up in the air still. ;)
| FOR identifier IN (SELECT * FROM "Identifiers") LOOP | ||
| -- Create a "blank" Profile | ||
| INSERT INTO "Profiles"("name", "accountSid", "createdAt", "updatedAt") | ||
| VALUES (NULL, identifier."accountSid", current_timestamp, current_timestamp) |
There was a problem hiding this comment.
Would some sort of name not be preferable if only to make debugging easier? Or does your logic require these autogenerated profiles to have a null name?
There was a problem hiding this comment.
We haven't decided on how to populate the name field yet. It is null temporarily until those choices are made. We know it will be needed, but for now there are still discussions around what to populate it with.
| DO $$ | ||
| DECLARE tmp RECORD; | ||
| BEGIN | ||
| FOR tmp IN ( |
There was a problem hiding this comment.
The FROM clause in the UPDATE statement can be used to update tables with data from other tables (or the same table with a self join): https://www.postgresql.org/docs/current/sql-update.html
In this case, instead of using a loop you could do this update in a single query, something like:
UPDATE "Contacts" c SET "profileId" = tmp."profileId", "identifierId" = tmp."identifierId"
FROM "ProfilesToIdentifiers" p2i
LEFT JOIN "Identifiers" ids ON p2i."identifierId" = ids.id
WHERE c."number" = ids."identifier" AND c."accountSid" = ids."accountSid";
Obvs loops are fine for migrations, but it's good practice to try to avoid them anyway, so you know how to tackle similar issues in places where you should be avoiding SQL loops if at all possible (i.e. production code).
Don't change this code if you have it working, just FYI for the future
Description
This PR:
number.numberis already saved.The tables structure is as in the following diagram.
For further details is refer to the below linked ticket.
Checklist
Verification steps
masterbranch, and save a few "live" contacts and a few "offline contacts".IdentifiersandProfilestables are populated with the presentnumbers in theContactstable.Contactstable is updated:profileIdandidentifierIdare populated ONLY for those records withnumber(no offline contacts).