-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
migration generation: update enumName for Postgres #5479
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
|
hmm i dont think this will do anything different, given that i just filled in what the code defaults to. hmmm not totally sure where the names get generated for migrations then... |
|
reverted the old changes (but left my previous ones in place for posterity of the approach, can remove those commits before merging later), and tried instead to modify |
|
after looking through the code I believe the names should be getting generated correctly but the migration generation code just isn't detecting the change, which gets called by each of the appropriate some details:in
i think so I guess |
0afc2fa to
4e28994
Compare
|
OK ready for a review again |
|
hmmm nm looks like i broke other tests, checking... |
|
@osdiab any eta on this pull request? |
|
@JipSterk sorry ended up focusing on other stuff on my company but i'll fix it up first thing tomorrow! (i'm on japan time) |
|
@JipSterk hopefully tests pass now, heading to bed but if they do should be ready for re-review from maintainers. |
|
@Kononnable @pleerock @AlexMesser ready for a review! |
|
@osdiab Thanks a bunch 🌈 |
|
Pinging on this @Kononnable @pleerock @AlexMesser |
|
Thanks for the fix @osdiab , once it gets merged, we'll use it! 👀 |
|
@Kononnable @pleerock @AlexMesser pinging again - any chance you can review? its been a month and a half and people are pinging me about when this will get merged lol |
|
pinging again, hope someone can review this... @pleerock @AlexMesser @Kononnable |
|
Im sorry for pinging again but would like to know some kind of ETA since it currently broken. @pleerock @AlexMesser @Kononnable |
|
I do not consider myself as part of typeorm team(or however we want to call it) for several months now, nor do I plan to come back to this role with the way things work here(not directly related to number of issues, prs). Because of that I won't be the one to merge this PR, so please don't ping me next time. All I can say is that I'm sorry for the state of the typeorm, but I don't think I will be the one who change it. At least not with its current organization structure which I doubt will be ever changed. |
This comment has been minimized.
This comment has been minimized.
|
Calling out to @imnotjames since I see you've been active lately on TypeORM and this PR's been waiting for a while! |
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.
Looks pretty good. Probably didn't need to change variable names which could have made this change smaller.
Does this leave the _old around? Does it ever clean it up?
| if (newColumn.default !== null && newColumn.default !== undefined) { | ||
| upQueries.push(new Query(`ALTER TABLE ${this.escapePath(table)} ALTER COLUMN "${newColumn.name}" DROP DEFAULT`)); | ||
| downQueries.push(new Query(`ALTER TABLE ${this.escapePath(table)} ALTER COLUMN "${newColumn.name}" SET DEFAULT ${newColumn.default}`)); | ||
| downQueries.push(new Query(`ALTER TABLE ${this.escapePath(table)} ALTER COLUMN "${newColumn.name}" SET DEFAULT ${oldColumn.default}`)); |
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 this correct? This is setting to the old column def default
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.
It's counterintuitive but I believe it's correct - lines 733 - 749 are a block together, if you read the up queries in order from top down and the down queries from bottom up, they match one another i believe - its been a while since i've looked at this but i believe what's going on is applying the oldColumn.default value restores whatever was previously the default. Though perhaps we should be only doing this logic if the old column had a default at all, rather than always. a test for this would probably also be helpful!
| if (oldColumn.isNullable !== newColumn.isNullable) { | ||
| if (newColumn.isNullable) { | ||
| upQueries.push(new Query(`ALTER TABLE ${this.escapePath(table)} ALTER COLUMN "${oldColumn.name}" DROP NOT NULL`)); | ||
| upQueries.push(new Query(`ALTER TABLE ${this.escapePath(table)} ALTER COLUMN "${newColumn.name}" DROP NOT NULL`)); |
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.
Switched from old column to new column. Intended?
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.
At this point i believe technically oldColumn shouldn't exist, it would have already been renamed. but that said, i dont believe that the postgres generated migrations actually ever rename a column (always seems to drop and recreate) so it may be a moot point.
| downQueries.push(new Query(`ALTER TABLE ${this.escapePath(table)} ALTER COLUMN "${oldColumn.name}" SET NOT NULL`)); | ||
| } else { | ||
| upQueries.push(new Query(`ALTER TABLE ${this.escapePath(table)} ALTER COLUMN "${oldColumn.name}" SET NOT NULL`)); | ||
| upQueries.push(new Query(`ALTER TABLE ${this.escapePath(table)} ALTER COLUMN "${newColumn.name}" SET NOT NULL`)); |
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.
Old column to new column via diff. Intentional?
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.
yeah, see above - i think lol. need to review my old code or maybe write some extra tests to make sure haha.
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 - once you're ready, re-request my review.
|
hey @osdiab i was just checking in on the status of the pr. i hope you have some spare time to close this issue. keep safe & keep sane 🌈❤️ |
|
sorry for the delay, will take a look soon! thanks for the reminder. |
|
@JipSterk sorry still on my radar but just haven't had the time. Hopefully will get to it this week. |
Resolves #5478 for Postgres databases (which is what I use, so I didn't do this for the other drivers).
If you add an
enumNamefield for an entity's column, generated migrations for Postgres will now properly edit the name of the enum for that column.Old comment
this is my
firstsecond! code contribution so I want to make sure I'm going the right direction before I put a bunch of effort applying this kind of change all over the place.Still need to figure out how this repo does tests for things like this, how i can try it out to see if it works
My understanding is that the query building in the individual drivers determines whether or not a change in a generated migration will actually get outputted - and i noticed that the optional enumName parameter wasn't being passed in in a lot of cases. this makes it non-optional to force the client code to provide something, as a way to smoke out all the places where it may be missing.