-
Notifications
You must be signed in to change notification settings - Fork 14
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
Typeorm updation #1606
Typeorm updation #1606
Conversation
…ry unit test case
…/UpGrade into upgrade/1282-typeorm
…into upgrade/1282-typeorm
(cherry picked from commit 4e7a6ee)
…into upgrade/1282-typeorm
Currently all of our CL client lib usage is on 5.0, which is fine right now, 5.1 is not required. When this code gets promoted, since still synced with 5.2 shouldn't be required either. Are we sure that this 5.2 TypeOrm update version won't break compatibility with CL apps using 5.0? I ask because a change like this should not be merged in yet, that would break all of our clients on staging and we would need to get them to update their libraries / usage. Can we maybe cease pulling dev and "freeze" into branch this so we don't pull in accidental surprises? Then we can pip dev to like 5.3? @VivekFitkariwala @RidhamShah @bcb37 |
@@ -1014,7 +1014,7 @@ export class ExperimentClientController { | |||
@Delete('clearDB') | |||
public async clearDB(@Req() request: AppRequest): Promise<string> { | |||
// if DEMO mode is enabled, then clear the database: | |||
if (env.app.demo) { | |||
if (!env.app.demo) { |
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 this change?
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.
please remove. i have to assume someone was doing this in debugging and accidentally committed it, if this change snuck into prod, anyone with a token would be able to delete our database by doing DELETE /clearDB
. It makes me nervous even having this endpoint exist in the first place for this exact reason.
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.
code updated
return { userId: individual.userId, segment: segment.id }; | ||
}); | ||
await transactionalEntityManager.getRepository(IndividualForSegment).delete(usersToDelete as any); | ||
// const usersToDelete = segmentDoc.individualForSegment.map((individual) => { |
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.
if the commented code isn't needed anymore, let's get rid of it, we can see the old implementation in git history
@@ -22,6 +22,7 @@ LOG_OUTPUT=dev | |||
# | |||
TYPEORM_CONNECTION=postgres | |||
TYPEORM_HOST=localhost | |||
TYPEORM_HOSTNAME_EXPORT_REPLICA=[] |
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.
is the separate new env var needed for the typeorm update? does it need to be an array if it's just one thing?
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.
No, it was part of improvement we found while updating replica connection syntax during this PR. Its kept as an array for consistency with the other replica hostnames var. We can make it a string if you want.
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.
ok, this complicates promoting this to production as it's an unexpected configuration change that I don't remember being talked about. @bcb37 @VivekFitkariwala what do you think
Seeing these errors when doing /assign to a context with any experiments enrolling (not just group). I see same thing in local as when I deployed this branch into our staging environment. { |
@@ -1014,7 +1014,7 @@ export class ExperimentClientController { | |||
@Delete('clearDB') | |||
public async clearDB(@Req() request: AppRequest): Promise<string> { | |||
// if DEMO mode is enabled, then clear the database: | |||
if (env.app.demo) { | |||
if (!env.app.demo) { |
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.
please remove. i have to assume someone was doing this in debugging and accidentally committed it, if this change snuck into prod, anyone with a token would be able to delete our database by doing DELETE /clearDB
. It makes me nervous even having this endpoint exist in the first place for this exact reason.
Can someone please report out exactly what the breaking changes are in this code that we should be aware of? This branch will essentially be promoted directly to staging and then to prod as its own release apart from dev. There are definitely some commits that exist in 5.1 that I recall being asked to not merge down into dev, please check that also. |
…into upgrade/1282-typeorm
Tested the changes in local and in staging with some quick running of locust tests just to get a sense of the API working, looks good no errors, times looked good also. Here are my notes on things that need changed for deploying to production. Please help me to note other things to check with this update so we are sure prod's version (release/v5.1) is not going to break when we deploy this branch. notes: TYPEORM_HOSTNAME_EXPORT_REPLICA is a new var, what is the correct usage? Is does this replace the other replica array? @bcb37 we should find an hour or so to swap in the db one more time and test it together |
Yeah Now, the export replica hostname would also be an array as a separate env variable Ridham has reverted that delete api change. |
This PR covers below changes:
TYPEORM_HOSTNAME_EXPORT_REPLICA
and rest replicas (if any) would be in theTYPEORM_HOSTNAME_REPLICAS
. For now you need to move the value inTYPEORM_HOSTNAME_REPLICAS
toTYPEORM_HOSTNAME_EXPORT_REPLICA
.typeormLoader
file to have the mainDB connection use the 2nd read replica as slaves which will be automatically used for any read operation that uses the main DB connection by default. Only the export queries would use the export connection which will hit the 1st read replica. In case we dont have a 2nd read replica, all the reads apart from export queries would hit the main RDS instance.