Skip to content
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

Postgres - Add schema name support in x-migrations-table value (#95) #483

Conversation

stephane-klein
Copy link
Contributor

@stephane-klein stephane-klein commented Nov 28, 2020

@dhui what do you think about this commit which add x-schema-name URL Query support as suggest by this comment?

Is anything missing to approve this Pull Request? Some documention, unit test or other?

Best regards,

Stéphane


Edit:

The second version of this patch add schema name support in x-migrations-table value.

Now, you can use:

migrate ... -database ...?x-migrations-table=gomigrate.schema_migrations

Edit: alternative implementation: #533

@stephane-klein
Copy link
Contributor Author

Warning, there is a bug in this Pull Request, I'm going to fix it.

@stephane-klein stephane-klein force-pushed the 95-postgres-add-x-schema-name-url-query-option branch from f8f6366 to e800222 Compare November 28, 2020 20:16
@stephane-klein
Copy link
Contributor Author

Warning, there is a bug in this Pull Request, I'm going to fix it.

Fixed.

Copy link
Member

@dhui dhui left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you have issues with search_path? Thinking more about this, having 2 ways to set the same thing increases complexity.

database/postgres/README.md Outdated Show resolved Hide resolved
database/postgres/README.md Outdated Show resolved Hide resolved
@stephane-klein
Copy link
Contributor Author

Did you have issues with search_path? Thinking more about this, having 2 ways to set the same thing increases complexity.

@dhui yes, I have some internal product constraint, I can't change the search_path value 😞

@stephane-klein stephane-klein force-pushed the 95-postgres-add-x-schema-name-url-query-option branch 2 times, most recently from e6653da to f01f70f Compare November 29, 2020 10:28
@stephane-klein
Copy link
Contributor Author

stephane-klein commented Nov 29, 2020

Rename to x-migrations-schema-name if only used for the migrations table. Otherwise, if we use the name x-schema-name, we should set the current schema after connecting.
  • Document how this interacts with search_path
  • migratations -> migrations

@stephane-klein
Copy link
Contributor Author

Did you have issues with search_path? Thinking more about this, having 2 ways to set the same thing increases complexity.

👍

I'm working on a refactoring of this Pull Request.

@stephane-klein stephane-klein force-pushed the 95-postgres-add-x-schema-name-url-query-option branch from f01f70f to 884e325 Compare November 29, 2020 14:23
@stephane-klein stephane-klein changed the title Postgres - Add x-schema-name URL Query support (#95) Postgres - Add schema name support in x-migrations-table value (#95) Nov 29, 2020
@stephane-klein
Copy link
Contributor Author

The second version of this patch add schema name support in x-migrations-table value.

Now, you can use:

migrate ... -database ...?x-migrations-table=gomigrate.schema_migrations

@dhui what do you think about this second implementation?

Copy link
Member

@dhui dhui left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for addressing my feedback; this approach is much better!

database/postgres/postgres.go Outdated Show resolved Hide resolved
database/postgres/postgres.go Outdated Show resolved Hide resolved
@stephane-klein stephane-klein force-pushed the 95-postgres-add-x-schema-name-url-query-option branch 2 times, most recently from 5355d15 to 7e41a9a Compare December 6, 2020 14:24
@stephane-klein
Copy link
Contributor Author

@dhui new need review 🙂

database/postgres/postgres.go Outdated Show resolved Hide resolved
database/postgres/postgres.go Outdated Show resolved Hide resolved
@stephane-klein stephane-klein force-pushed the 95-postgres-add-x-schema-name-url-query-option branch from 7e41a9a to 81fd8bd Compare December 13, 2020 19:55
@stephane-klein
Copy link
Contributor Author

@dhui need review 😉

Copy link
Member

@dhui dhui left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks again for addressing another round of feedback!

database/postgres/postgres.go Outdated Show resolved Hide resolved
@phungleson
Copy link

Hi @stephane-klein thanks for working on this, this feature is kind of neat.

I wonder if we can get this merge soon? thanks again, cheers

@dhui
Copy link
Member

dhui commented Dec 22, 2020

FYI, merges are blocked until we move off of TravisCI

@stephane-klein stephane-klein force-pushed the 95-postgres-add-x-schema-name-url-query-option branch from 81fd8bd to 0c7e31d Compare December 24, 2020 18:13
@stephane-klein
Copy link
Contributor Author

We need to handle the case when there are multiple .

@dhui What do you think about this proposition which support multiples .?

I have also added Test_quoteIdentifier test.

Copy link
Member

@dhui dhui left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks again for addressing my feedback!

database/postgres/postgres_test.go Show resolved Hide resolved
func (p *Postgres) quoteIdentifier(name string) string {
if p.config.MigrationsTableHasSchema {
firstDotPosition := strings.Index(name, ".")
if firstDotPosition != -1 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we error if a . is not found?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we error if a . is not found?

@dhui Why? I suggest to use default schema if . not found in table name.

Do you think this is a bad idea? Do you prefer that schema name must be mandatory?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Falling back to search_path makes sense. The behavior isn't obvious based on the config name, so could you update the docs to mention that . is not required?

if p.config.MigrationsTableHasSchema {
firstDotPosition := strings.Index(name, ".")
if firstDotPosition != -1 {
return pq.QuoteIdentifier(name[0:firstDotPosition]) + "." + pq.QuoteIdentifier(name[firstDotPosition+1:])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We error if more than one . is found or document the behavior. e.g. the first dot is treated as the schema and table name separator.

Another approach I just thought of is to have an option to treat the identifier as already quoted. e.g. you'd pass in "myschema"."mytable" and we'd just check that the string starts and ends with ". Thoughts?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or document the behavior. e.g. the first dot is treated as the schema and table name separator.

@dhui I chose to document it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another approach I just thought of is to have an option to treat the identifier as already quoted. e.g. you'd pass in "myschema"."mytable" and we'd just check that the string starts and ends with ". Thoughts?

Do you think that this is a better approach ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think having an option to treat the identifier as already quoted and requiring that the identifier starts and ends with a " is a simpler approach since we're not parsing the identifer so there are fewer opportunities for unexpected behaviors
What do you think?

If we go with the pre-quoted identifier approach, what do you think of the config name x-migrations-table-quoted?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think having an option to treat the identifier as already quoted and requiring that the identifier starts and ends with a " is a simpler approach since we're not parsing the identifer so there are fewer opportunities for unexpected behaviors
What do you think?

@dhui This is a new Pull Request with this implementation: #533

@stephane-klein stephane-klein force-pushed the 95-postgres-add-x-schema-name-url-query-option branch from 0c7e31d to e21a1b8 Compare December 26, 2020 21:47
…g-migrate#95)

Add x-migrations-table-has-schema to enable schema name support in x-migrations-table value.
@stephane-klein stephane-klein force-pushed the 95-postgres-add-x-schema-name-url-query-option branch from e21a1b8 to 820ec91 Compare December 26, 2020 21:51
@stephane-klein
Copy link
Contributor Author

@dhui need review 🙂

@stephane-klein
Copy link
Contributor Author

@dhui Small pump 😉

@dhui
Copy link
Member

dhui commented Jan 6, 2021

@stephane-klein Sorry for the delay, was busy over the holidays. I've replied to your comments. Thanks for your patience and for pushing this PR through!

@rivvid
Copy link

rivvid commented Mar 5, 2021

Would love to see this feature merged -- don't want to use the public schema to store the migrations list -- if you have more than 1 service sharing a DB but using different schemas, the current implementation will not work.

@FAQinghere
Copy link

FAQinghere commented Mar 24, 2021

I might be misunderstanding something, but it seems like we already provide a config for migrations, and it already has the option for the schema to be specified. So if we just change the existing implementation to respect the config value (see:

query = `CREATE TABLE IF NOT EXISTS ` + pq.QuoteIdentifier(p.config.MigrationsTable) + ` (version bigint not null primary key, dirty boolean not null)`
) then wouldn’t it work without adding all this complexity? Compare this to the line just above where it does SELECT current_schema() for the migrations connection (
query := `SELECT COUNT(1) FROM information_schema.tables WHERE table_name = $1 AND table_schema = (SELECT current_schema()) LIMIT 1`
). I think it should just respect p.config.SchemaName?

Sorry if this isn’t expressed correctly. I did this in a local fork maybe 18 months back on a project where I had to make sure migrations were saved in a table in a schema other than the one I was connected on, and I think I remember getting it to work with only a tiny tweak. But that was a long time ago and maybe I’m misremembering. IIRC I fixed it to respect that config value when creating/checking the migrations table. I used WithInstance directly so I controlled the connection, and was connected as admin user on admin schema, but the migrations were written to the non-admin schema that I set in the Config.SchemaName. It might have been just 1 or 2 lines maybe. Unfortunately I don’t have access to it anymore. Hopefully that contributed food for thought. If not, sorry for the noise.

@stephane-klein
Copy link
Contributor Author

This PullRequest is replaced by #533

When #533 will be merged, I'll close this current Pull Request.

@stephane-klein
Copy link
Contributor Author

then wouldn’t it work without adding all this complexity?

@FAQinghere simplest implementation here: #533

@StevenACoffman
Copy link

@stephane-klein #533 is merged, did you mean to close this PR?

@dhui
Copy link
Member

dhui commented Aug 2, 2022

As @StevenACoffman mentioned, this PR is superseded by #533

@dhui dhui closed this Aug 2, 2022
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.

6 participants