Skip to content

Conversation

@osdiab
Copy link
Contributor

@osdiab osdiab commented Feb 5, 2020

Resolves #5478 for Postgres databases (which is what I use, so I didn't do this for the other drivers).

If you add an enumName field 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 first second! 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.

@osdiab
Copy link
Contributor Author

osdiab commented Feb 5, 2020

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...

@osdiab
Copy link
Contributor Author

osdiab commented Feb 5, 2020

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 findChangedColumns() (in postgres only for now) to check for changed enum name. maybe this is the right way to go?

@osdiab
Copy link
Contributor Author

osdiab commented Feb 5, 2020

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 SchemaBuilder.log() -> RdbmsSchemaBuilder.updateExistColumns() -> driver.findChangedColumns() calls i believe

some details:

in PostgresDriver, createEnumTypeSql() is called in

  • addColumn()
  • createTable()
  • changeColumns()
  • dropColumn()

i think createTable(), addColumn() and dropColumn() should all be fine because the createEnumTypeSql() method already produces the correct names and fresh uses/outright deletion aren't the problem here.

so I guess changeColumns() needs to be called, which is done for RDBMS's in the RdbmsSchemaBuilder.updateExistColumns() method - so I think what I did might be on the right track then. Need to figure out how to try it out now

@osdiab osdiab changed the title WIP: set enum name for more queries set enum name for more queries for Postgres Feb 27, 2020
@osdiab osdiab changed the title set enum name for more queries for Postgres migration generation: update enumName for Postgres Feb 27, 2020
@osdiab
Copy link
Contributor Author

osdiab commented Feb 27, 2020

cc @pleerock @AlexMesser @Kononnable

@osdiab osdiab force-pushed the osdiab/enumname-migrations branch from 0afc2fa to 4e28994 Compare February 27, 2020 12:37
@osdiab
Copy link
Contributor Author

osdiab commented Mar 6, 2020

OK ready for a review again

@osdiab
Copy link
Contributor Author

osdiab commented Mar 6, 2020

hmmm nm looks like i broke other tests, checking...

@JipSterk
Copy link

@osdiab any eta on this pull request?

@osdiab
Copy link
Contributor Author

osdiab commented May 28, 2020

@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)

@osdiab
Copy link
Contributor Author

osdiab commented May 29, 2020

@JipSterk hopefully tests pass now, heading to bed but if they do should be ready for re-review from maintainers.

@osdiab
Copy link
Contributor Author

osdiab commented May 30, 2020

@Kononnable @pleerock @AlexMesser ready for a review!

@JipSterk
Copy link

@osdiab Thanks a bunch 🌈

@osdiab
Copy link
Contributor Author

osdiab commented Jun 10, 2020

Pinging on this @Kononnable @pleerock @AlexMesser

@davidlj95
Copy link

Thanks for the fix @osdiab , once it gets merged, we'll use it! 👀

@osdiab
Copy link
Contributor Author

osdiab commented Jul 8, 2020

@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

@osdiab
Copy link
Contributor Author

osdiab commented Jul 15, 2020

pinging again, hope someone can review this... @pleerock @AlexMesser @Kononnable

@JipSterk
Copy link

Im sorry for pinging again but would like to know some kind of ETA since it currently broken. @pleerock @AlexMesser @Kononnable

@Kononnable
Copy link
Contributor

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.

@osdiab

This comment has been minimized.

@osdiab
Copy link
Contributor Author

osdiab commented Oct 7, 2020

Calling out to @imnotjames since I see you've been active lately on TypeORM and this PR's been waiting for a while!

@imnotjames imnotjames self-requested a review October 7, 2020 07:57
Copy link
Contributor

@imnotjames imnotjames left a 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}`));
Copy link
Contributor

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

Copy link
Contributor Author

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`));
Copy link
Contributor

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?

Copy link
Contributor Author

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`));
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

@JipSterk
Copy link

JipSterk commented Nov 9, 2020

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 🌈❤️

@osdiab
Copy link
Contributor Author

osdiab commented Nov 13, 2020

sorry for the delay, will take a look soon! thanks for the reminder.

@osdiab
Copy link
Contributor Author

osdiab commented Dec 15, 2020

@JipSterk sorry still on my radar but just haven't had the time. Hopefully will get to it this week.

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.

Setting enumName doesn't change how migrations get generated

7 participants