Use the schema_search_path in prepared statements. #3232

Merged
merged 2 commits into from Oct 7, 2011

Conversation

Projects
None yet
4 participants
Contributor

Juanmcuello commented Oct 5, 2011

I'm using postgreSQL with multiple schemas.

Rails 3.1 uses prepared statements and does not take into account the 'schema_search_path'. This is a big problem because the statement is prepared once and then the same prepared statement is executed many times no matter if you changed the schema, i.e, the prepared statement is executed ALWAYS for the same schema, the one set when the statement was prepared.

This patch adds the schema search to the sql key to allow the use of prepared statements when changing schemas in postgreSQL,

Discussion here:
https://groups.google.com/forum/#!msg/rubyonrails-core/r2VOKcyUyrs/JQj4MB_lhRMJ

Use the schema_search_path in prepared statements.
To allow the use of prepared statements when changing schemas in
postgres, the schema search path is added to the sql key.
Owner

tenderlove commented Oct 5, 2011

Can you write a test for this? We have schema tests for PG in the active record suite.

refs #3232. Prepared statements and postgreSQL schemas.
Add tests for prepared statements with multiple schemas in
postgreSQL.
Contributor

Juanmcuello commented Oct 5, 2011

Done!

Owner

tenderlove commented Oct 7, 2011

Great! Thank you! ❤️

tenderlove added a commit that referenced this pull request Oct 7, 2011

Merge pull request #3232 from Juanmcuello/pg_prepared_statements
Use the schema_search_path in prepared statements.

@tenderlove tenderlove merged commit 3088d23 into rails:master Oct 7, 2011

Thank you for creating this patch! This problem was driving me crazy until I found your post on the topic. Until this patch is "officially released" in an upcoming version of Rails, I'm working around the problem by calling

ActiveRecord::Base.connection.clear_cache! # HACK: Workaround

...just before setting a new search path. I'm not familiar with the Rails release process, but I hope this fix is included in the next version.

Contributor

Juanmcuello commented Nov 4, 2011

I hope so too! Meanwhile, I'm using the same workaround.

Good to know the patch works for you. :)

Contributor

Juanmcuello commented Nov 14, 2011

@jonleighton, any chance to include this in next 3.1.2 release?

Member

jonleighton commented Nov 14, 2011

The RC has already gone out but I am pretty sure this is in there - check the CHANGELOG though.

Member

jonleighton commented Nov 14, 2011

Actually, doesn't look like it is in the release, sorry.

It's too late now to put it in I'm afraid. If you'd like it in the next release, please submit a pull request with a backport. Thanks.

Contributor

Juanmcuello commented Nov 14, 2011

After digging a while into git history, I think this is what happened:

In master branch, part of the code introduced by cfc95d8 (included in this pull request) was later modified in 6a28c51.

Instead of porting the two commits to 3.1.2, only the last commit was ported. It was not ported exactly as it was, it was modified instead, and the changes included code from the first commit (???). This changes resulted in commit 818d285.

This pull request also includes tests, but they were not ported to 3.1.2 at all.

So, the problem solved by this pull request seems to be already solved in 3.1.2 by 818d285. The only missing part are tests.

Do I create a pull request to back-port tests?

Member

jonleighton commented Nov 14, 2011

Ok, thanks for looking into it :)

If you can create a PR with the tests and a CHANGELOG entry (under 3.1.2) that would be great. Thanks.

jonleighton added a commit that referenced this pull request Nov 15, 2011

jonleighton added a commit that referenced this pull request Nov 15, 2011

@Juanmcuello Juanmcuello deleted the Juanmcuello:pg_prepared_statements branch Nov 16, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment