Client's Schema config does nothing
#15
Comments
|
Ah, yeah we never got around to implementing this. We can either nuke the setting for now, or try to make the required fixes to make it work. I expect it will come up as a requested setting. Even without explicit support for this, the user could already be setting a |
|
Actually, good point on using pgx to configure it — I kinda like that, although we'd definitely need a section in the docs explaining how to do it because it wouldn't be obvious. The CLI migrator would probably still need to support a |
|
@brandur you can actually set So maybe the CLI already works with it too? |
|
Oh awesome! Another thing we'll have to document because it's pretty non-obvious, but yes, that should solve our problems for now. |
brandur
added a commit
that referenced
this issue
Nov 13, 2023
As discussed in #15, the `Schema` configuration parameter doesn't actually do anything, and we realized that it's possible to support this feature by using an alternate configuration for pgxpool in `search_path`. Here, drop `Schema` and add a test that verifies that this technique works. So as to not have to create and migrate an alternate schema, we cheat a little bit by repointing the schema and then just verifying that we can't find a `river_job` table there. I'm finding the test hierarchy in `client_test.go` to be pretty confusing in determining on what best practice is for what should go where, so I'm starting out with a new `Test_Client` which I'm hoping we can start using as a base for most of the general tests in here in a more reusable way. I leverage `JobArgsReflectKind` and `WorkFunc` in its subtests so that it's not dependent on our various global job args that are defined all over the place. Instead, args and the work routine are colocated right inside the test. Configuring an alternate schema is definitely going to need its own documentation page somewhere because it's not obvious, but that'll come separately.
brandur
added a commit
that referenced
this issue
Nov 13, 2023
As discussed in #15, the `Schema` configuration parameter doesn't actually do anything, and we realized that it's possible to support this feature by using an alternate configuration for pgxpool in `search_path`. Here, drop `Schema` and add a test that verifies that this technique works. So as to not have to create and migrate an alternate schema, we cheat a little bit by repointing the schema and then just verifying that we can't find a `river_job` table there. I'm finding the test hierarchy in `client_test.go` to be pretty confusing in determining on what best practice is for what should go where, so I'm starting out with a new `Test_Client` which I'm hoping we can start using as a base for most of the general tests in here in a more reusable way. I leverage `JobArgsReflectKind` and `WorkFunc` in its subtests so that it's not dependent on our various global job args that are defined all over the place. Instead, args and the work routine are colocated right inside the test. Configuring an alternate schema is definitely going to need its own documentation page somewhere because it's not obvious, but that'll come separately. Fixes #15.
brandur
added a commit
that referenced
this issue
Nov 13, 2023
As discussed in #15, the `Schema` configuration parameter doesn't actually do anything, and we realized that it's possible to support this feature by using an alternate configuration for pgxpool in `search_path`. Here, drop `Schema` and add a test that verifies that this technique works. So as to not have to create and migrate an alternate schema, we cheat a little bit by repointing the schema and then just verifying that we can't find a `river_job` table there. I'm finding the test hierarchy in `client_test.go` to be pretty confusing in determining on what best practice is for what should go where, so I'm starting out with a new `Test_Client` which I'm hoping we can start using as a base for most of the general tests in here in a more reusable way. I leverage `JobArgsReflectKind` and `WorkFunc` in its subtests so that it's not dependent on our various global job args that are defined all over the place. Instead, args and the work routine are colocated right inside the test. Configuring an alternate schema is definitely going to need its own documentation page somewhere because it's not obvious, but that'll come separately. Fixes #15.
brandur
added a commit
that referenced
this issue
Nov 13, 2023
As discussed in #15, the `Schema` configuration parameter doesn't actually do anything, and we realized that it's possible to support this feature by using an alternate configuration for pgxpool in `search_path`. Here, drop `Schema` and add a test that verifies that this technique works. So as to not have to create and migrate an alternate schema, we cheat a little bit by repointing the schema and then just verifying that we can't find a `river_job` table there. I'm finding the test hierarchy in `client_test.go` to be pretty confusing in determining on what best practice is for what should go where, so I'm starting out with a new `Test_Client` which I'm hoping we can start using as a base for most of the general tests in here in a more reusable way. I leverage `JobArgsReflectKind` and `WorkFunc` in its subtests so that it's not dependent on our various global job args that are defined all over the place. Instead, args and the work routine are colocated right inside the test. Configuring an alternate schema is definitely going to need its own documentation page somewhere because it's not obvious, but that'll come separately. Fixes #15.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Unless I'm mistaken, the
Schemaoption that can be sent to a client doesn't do anything.I think all we need to do is to make sure to run
SET SCHEMA 'xxx'on every new connection?Also, even if this feature did work, the migration tool doesn't currently support an alternate schema, so that needs to be corrected too.
cc @bgentry
The text was updated successfully, but these errors were encountered: