Prepare Release 2.5.0 #44
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Support rails 6.1
…ment current schema
When monkeypatching the table name a series of other problems were showing up in our application due to Rails caching mechanism. After digging in the internals of active record, and given that this is only for postgresql schemas, it made more sense to update the arel table visitor to include the schema in the table name when building the query. This way the tables will always be prepended with the schema. This has been feature flagged to keep the default behaviour the same as before. The find_by cache key has also been revisited. This way, the cached find_by statements will be cached with tenant information in the cache key, avoiding the colliding keys when switching tenants. E.g. Setting.find_by(key: 'something', string_value: 'amazing') would cache the query "SELECT \"settings\".* FROM \"public\".\"settings\" WHERE \"settings\".\"key\" = $1 AND \"settings\".\"string_value\" = $2 LIMIT $3" with the proper binds, but associated with the key [:key, :string_value]. This meant that when switching tenants and running the same query again, we would get the previous result. Adding the tenant to the array of keys for the cache solves the issue.
# Ruby changes Updated minor versions of ruby used for the test suites and added missing versions: - from 2.4.3 to 2.4.10 - from 2.5.0 to 2.5.8 - from 2.6.2 to 2.6.6 - added 2.7.1 - added jruby-head # Travis updates - Do not uninstall bundler 2.x # Gemspec updates - Relax bundler development dependency
- Cached find by statement can also receive one single string value for key as "id", when running Setting.find(10). This was causing the cache key to fail to build
…nant - Monkeypatch `connected_to` rails active record method to try to ensure that whenever we switch connection we connect to the proper tenant - Removed `allow_prepend_tenant_name` configuration because we ran into concurrency issues. When the connection goes back to the pool its attributes are set with the old values and we were getting queries being made to the wrong tenant. I still think that using this prepend_tenant seems like a good idea but I'll need further testing and investigation on how to make it safe. There is a bug reported in the original apartment gem that seems to report similar issues (influitive/apartment#186)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.