| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
