| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit f656bb301a43fe441af0039e4fafe40a7faa62f8.
Reason: Test in Action View expects the `collection_cache_key` working...
https://github.com/rails/rails/blob/ff6b713f5e729859995f204093ad3f8e08f39ea8/actionview/test/activerecord/relation_cache_test.rb#L21
https://github.com/rails/rails/blob/ff6b713f5e729859995f204093ad3f8e08f39ea8/actionview/test/fixtures/project.rb#L6
https://buildkite.com/rails/rails/builds/60609#d19181fb-fe80-4d1e-891c-1109b540fb4b/981-1009
|
|
|
|
|
|
|
|
|
| |
The `collection_cache_key` is private API for a long time, but I've
maintained it in #35848 since it is mentioned in the doc
(https://github.com/rails/rails/pull/35848#discussion_r272011475).
The doc has removed at 1da9a7e4, so there is no longer a reason to
maintain that private API.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cache versioning enables the same cache key to be reused when the object
being cached changes by moving the volatile part of the cache key out of
the cache key and into a version that is embedded in the cache entry.
This is already occurring when the object being cached is an
`ActiveRecord::Base`, but when caching an `ActiveRecord::Relation`
we are currently still putting the volatile information (max updated at
and count) as part of the cache key.
This PR moves the volatile part of the relations `cache_key` into the
`cache_version` to support recycling cache keys for
`ActiveRecord::Relation`s.
|
|
|
|
| |
Change query to use alias name for timestamp_column to avoid ambiguity problems when using timestamp from subquery.
|
|
|
|
|
|
|
|
|
| |
`test_update_does_not_run_sql_if_record_has_not_changed` would pass
without #18501 since `assert_queries` ignores BEGIN/COMMIT unless
`ignore_none: true` is given.
Since #32647, empty BEGIN/COMMIT is ommited. So we no longer need to use
`assert_queries(0)` to ignore BEGIN/COMMIT in the queries.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the time the table and predicate_builder
passed to Relation.new are exactly the
arel_table and predicate builder of the
given klass. This uses klass.arel_table
and klass.predicate_builder as the defaults,
so we don't have to pass them in most cases.
This does change the signaure of both Relation and
AssocationRelation. Are we ok with that?
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can't replace existing SELECT list as long as having DISTINCT, it
will cause incorrect result.
And also, PostgreSQL has a limitation that ORDER BY expressions must
appear in select list for SELECT DISTINCT.
Therefore, we should not replace existing SELECT list when using
DISTINCT.
Fixes #29779.
|
|
|
|
| |
We can't replace existing select list as long as referenced by ORDER BY.
|
|
|
|
|
|
|
|
| |
implementation
and defaults to `Digest::MD5`.
Replaced calls to `::Digest::MD5.hexdigest` with calls to `ActiveSupport::Digest.hexdigest`.
|
|
|
|
|
|
| |
is needed
Fixes #30315.
|
|
|
|
|
| |
Because `collection.table_name` doesn't respect table alias.
Use `collection.arel_attribute` instead.
|
| |
|
|
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| |
|
|
|
|
| |
\Z was a mistake of \z. Replace \Z to \z to prevent newly \Z added.
|
|
|
|
|
|
| |
`cache_key` includes the size of a relation. But if a relation is not
loadded, the size is not respected even if a relation has a limit. It
should be respected for consistency.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- We don't need the select scope added by user as we only want to max
timestamp and size of the collection. So we already know which columns
to select.
- Additionally having user defined columns in select scope blows the cache_key
method with PostGreSQL because it needs all `selected` columns in the group_by
clause or aggregate function.
- Fixes #23038.
|
|
|
|
|
|
|
| |
- When relations return no result or 0 result then cache_key should
handle it gracefully instead of blowing up trying to access
`result[:size]` and `result[:timestamp]`.
- Fixes #23063.
|
|
|
|
|
|
|
|
|
| |
- Before this patch if we try to find cache_key of a loaded but empty
collection it used to give error because of trying to call `updated_at`
on `nil` value generated by
`collection.max_by(×tamp_column).public_send(timestamp_column)`.
- This commit fixes above error by checking if size is greater than zero
or not.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default timestamp used for AR is `updated_at` in nanoseconds! (:nsec) This causes issues on any machine that runs an OS that supports nanoseconds timestamps, i.e. not-OS X, where the cache_key of the record persisted in the database (milliseconds precision) is out-of-sync with the cache_key in the ruby VM.
This commit adds:
A test that shows the issue, it can be found in the separate file `cache_key_test.rb`, because
- model couldn't be defined inline
- transactional testing needed to be turned off to get it to pass the MySQL tests
This seemed cleaner than putting it in an existing testcase file.
It adds :usec as a dateformat that calculates datetime in microseconds
It sets precision of cache_key to :usec instead of :nsec, as no db supports nsec precision on timestamps
|
|
|
|
| |
encapsulate all arguments
|
|
|