-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Postgres - Add schema name support in x-migrations-table value (#95) #483
Conversation
Warning, there is a bug in this Pull Request, I'm going to fix it. |
f8f6366
to
e800222
Compare
Fixed. |
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.
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 |
e6653da
to
f01f70f
Compare
|
👍 I'm working on a refactoring of this Pull Request. |
f01f70f
to
884e325
Compare
@dhui what do you think about this second implementation? |
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.
Thanks for addressing my feedback; this approach is much better!
5355d15
to
7e41a9a
Compare
@dhui new need review 🙂 |
7e41a9a
to
81fd8bd
Compare
@dhui need review 😉 |
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.
Thanks again for addressing another round of feedback!
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 |
FYI, merges are blocked until we move off of TravisCI |
81fd8bd
to
0c7e31d
Compare
@dhui What do you think about this proposition which support multiples I have also added |
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.
Thanks again for addressing my feedback!
func (p *Postgres) quoteIdentifier(name string) string { | ||
if p.config.MigrationsTableHasSchema { | ||
firstDotPosition := strings.Index(name, ".") | ||
if firstDotPosition != -1 { |
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.
Should we error if a .
is not found?
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.
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?
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.
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:]) |
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.
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?
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.
or document the behavior. e.g. the first dot is treated as the schema and table name separator.
@dhui I chose to document it.
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.
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 ?
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.
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
?
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.
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
0c7e31d
to
e21a1b8
Compare
…g-migrate#95) Add x-migrations-table-has-schema to enable schema name support in x-migrations-table value.
e21a1b8
to
820ec91
Compare
@dhui need review 🙂 |
@dhui Small pump 😉 |
@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! |
Would love to see this feature merged -- don't want to use the |
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: migrate/database/postgres/postgres.go Line 446 in 511ae9f
SELECT current_schema() for the migrations connection (migrate/database/postgres/postgres.go Line 434 in 511ae9f
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. |
@FAQinghere simplest implementation here: #533 |
@stephane-klein #533 is merged, did you mean to close this PR? |
As @StevenACoffman mentioned, this PR is superseded by #533 |
@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:
Edit: alternative implementation: #533