| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
When distributed over multiple logger calls the lines can become
intermixed with other log statements. Combining them into a single
logger call makes sure they always get logged together.
|
|
|
|
| |
after `/' operator"
|
|\
| |
| | |
Fix broken ASt build
|
| | |
|
| |
| |
| |
| | |
`ActiveStorage::Filename#parameters` was removed by #33829.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since 06ab7b27ea1c1ab357085439abacdb464f6742bf,
`GCSServiceTest#test_signed_URL_response_headers` is broken.
https://travis-ci.org/rails/rails/jobs/460454477#L7084-L7087
This seems to be due to lack of `content_type` at upload.
This is solved by specifying `conten_type`.
However, since the same content is also tested with `test_upload_with_content_type`,
it will be duplicated content, so I think that can remove `test_signed_URL_response_headers`.
|
|\ \
| |/
|/| |
Use raw time string from DB to generate ActiveRecord#cache_version
|
| | |
|
| |
| |
| |
| |
| |
| | |
When an `updated_at` column exists on the model, but is not available on the instance (likely due to a select), we should raise an error rather than silently not generating a cache_version. Without this behavior it's likely that cache entries will not be able to be invalidated and this will happen without notice.
This behavior was reported and described by @lsylvester in https://github.com/rails/rails/pull/34197#issuecomment-429668759.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently, the `updated_at` field is used to generate a `cache_version`. Some database adapters return this timestamp value as a string that must then be converted to a Time value. This process requires a lot of memory and even more CPU time. In the case where this value is only being used for a cache version, we can skip the Time conversion by using the string value directly.
- This PR preserves existing cache format by converting a UTC string from the database to `:usec` format.
- Some databases return an already converted Time object, in those instances, we can directly use `created_at`.
- The `updated_at_before_type_cast` can be a value that comes from either the database or the user. We only want to optimize the case where it is from the database.
- If the format of the cache version has been changed, we cannot apply this optimization, and it is skipped.
- If the format of the time in the database is not UTC, then we cannot use this optimization, and it is skipped.
Some databases (notably PostgreSQL) returns a variable length nanosecond value in the time string. If the value ends in a zero, then it is truncated For instance instead of `2018-10-12 05:00:00.000000` the value `2018-10-12 05:00:00` is returned. We detect this case and pad the remaining zeros to ensure consistent cache version generation.
Before: Total allocated: 743842 bytes (6626 objects)
After: Total allocated: 702955 bytes (6063 objects)
(743842 - 702955) / 743842.0 # => 5.4% ⚡️⚡️⚡️⚡️⚡️
Using the CodeTriage application and derailed benchmarks this PR shows between 9-11% (statistically significant) performance improvement versus the commit before it.
Special thanks to @lsylvester for helping to figure out a way to preserve the usec format and for helping with many implementation details.
|
|\ \
| | |
| | | |
Fix minor Active Storage docs typo [ci skip]
|
|/ / |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* Force content-type to binary on service urls for relevant content types
We have a list of content types that must be forcibly served as binary,
but in practice this only means to serve them as attachment always. We
should also set the Content-Type to the configured binary type.
As a bonus: add text/cache-manifest to the list of content types to be
served as binary by default.
* Store content-disposition and content-type in GCS
Forcing these in the service_url when serving the file works fine for S3
and Azure, since these services include params in the signature.
However, GCS specifically excludes response-content-disposition and
response-content-type from the signature, which means an attacker can
modify these and have files that should be served as text/plain attachments
served as inline HTML for example. This makes our attempt to force
specific files to be served as binary and as attachment can be easily
bypassed.
The only way this can be forced in GCS is by storing
content-disposition and content-type in the object metadata.
* Update GCS object metadata after identifying blob
In some cases we create the blob and upload the data before identifying
the content-type, which means we can't store that in GCS right when
uploading. In these, after creating the attachment, we enqueue a job to
identify the blob, and set the content-type.
In other cases, files are uploaded to the storage service via direct
upload link. We create the blob before the direct upload, which happens
independently from the blob creation itself. We then mark the blob as
identified, but we have already the content-type we need without having
put it in the service.
In these two cases, then, we need to update the metadata in the GCS
service.
* Include content-type and disposition in the verified key for disk service
This prevents an attacker from modifying these params in the service
signed URL, which is particularly important when we want to force them
to have specific values for security reasons.
* Allow only a list of specific content types to be served inline
This is different from the content types that must be served as binary
in the sense that any content type not in this list will be always
served as attachment but with its original content type. Only types in
this list are allowed to be served either inline or as attachment.
Apart from forcing this in the service URL, for GCS we need to store the
disposition in the metadata.
Fix CVE-2018-16477.
|
| |
| |
| |
| |
| |
| |
| | |
Trusting any GlobaID object when deserializing jobs can allow
attackers to access information that should not be accessible to them.
Fix CVE-2018-16476.
|
|\ \
| | |
| | | |
Additional types of ResultSet should not contain keys of #attributes_to_define_after_schema_loads
|
| | | |
|
| | |
| | |
| | |
| | | |
Follow up ba4e68f577efc76f351d30a2914e29942b97830e.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit f2ab8b64d4d46d7199f94c3e21021f414a4d259a, reversing
changes made to b9c7305dbe57931a153a540d49ae5d469af61a14.
Reason: `scope.take` is not the same with `scope.to_a.first`.
|
|\ \ \
| |/ /
|/| | |
Reuse code in AR::Association#find_target
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Before this patch, singular and collection associations
had different implementations of the #find_target method.
This patch reuses the code properly through extending the low level
methods.
|
|\ \ \
| | | |
| | | | |
Make it possible to override the implicit order column
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When calling ordered finder methods such as +first+ or +last+ without an
explicit order clause, ActiveRecord sorts records by primary key. This
can result in unpredictable and surprising behaviour when the primary
key is not an auto-incrementing integer, for example when it's a UUID.
This change makes it possible to override the column used for implicit
ordering such that +first+ and +last+ will return more predictable
results. For Example:
class Project < ActiveRecord::Base
self.implicit_order_column = "created_at"
end
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This reverts commit d52f74480ae46cd3de7ce697093136b01c7a2172.
Since 24adc20, the `Helpers` constant in the `ActiveRecord` namespace is
not referenced anymore.
|
|/ / /
| | |
| | |
| | | |
It should be referenced by full qualified name from Active Record.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Karma and Rollup (#34440)
* Rename .coffee files in ActionCable test suite in prep for decaffeination
* Decaffeinate ActionCable tests
* Replace Blade with Karma and Rollup to run ActionCable JS tests
- Add karma and qunit devDependencies
- Add test script to ActionCable package
- Use rollup to bundle ActionCable tests
- Use karma as the ActionCable JS test runner
* Replace vendored mock-socket with package devDependency in ActionCable
* Move ActionCable yarn install to TravisCI before_install config
* Clean up decaffeinated ActionCable tests to use consistent formatting
|
| | |
| | |
| | |
| | |
| | | |
We are dealing with the rack env so it is better to specify it in the
tests.
|
| | |
| | |
| | |
| | | |
Closes #34530.
|
|\ \ \
| | | |
| | | | |
Bump the minimum version of PostgreSQL to 9.3
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
https://www.postgresql.org/support/versioning/
- 9.1 EOLed on September 2016.
- 9.2 EOLed on September 2017.
9.3 is also not supported since Nov 8, 2018. https://www.postgresql.org/about/news/1905/
I think it may be a little bit early to drop PostgreSQL 9.3 yet.
* Deprecated `supports_ranges?` since no other databases support range data type
* Add `supports_materialized_views?` to abstract adapter
Materialized views itself is supported by other databases, other connection adapters may support them
* Remove `with_manual_interventions`
It was only necessary for PostgreSQL 9.1 or earlier
* Drop CI against PostgreSQL 9.2
|
|\ \ \ \
| |_|/ /
|/| | | |
Test when using MySQL `exec_query` returns `ActiveRecord::Result` all…
|
| |/ /
| | |
| | |
| | |
| | | |
When running `exec_query` with `INSERT` (or other write commands), MySQL
returns `ActiveRecord::Result`.
|
|\ \ \
| | | |
| | | | |
Use cache_key_with_version instead of cache_key for the example in Low-Level Caching [ci skip]
|
|/ / /
| | |
| | |
| | | |
Caching [ci skip]
|
| | |
| | |
| | |
| | | |
https://travis-ci.org/rails/rails/jobs/459534536#L1280
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
yahonda/sqlite3_returns_primary_key_in_expected_order
SQLite 3.7.16+ returns the order of the primary key columns
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
https://www.sqlite.org/releaselog/3_7_16.html
> 9 Enhance the PRAGMA table_info command so that the "pk" column is an increasing integer to show the order of columns in the primary key.
Rails 6 supports SQLite 3.8 then we can remove this skip condition.
|
|\ \ \
| |/ /
|/| | |
Updating the Testing Guide to Reflect Emails Enqueued With ActiveJob
|
|/ / |
|
| | |
|
|\ \
| | |
| | | |
Remove unnecessary reduce in Duration#inspect
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When the `Duration` class was introduced in 276c9f29, the `parts` were
represented as an array of arrays
(for example `[[:seconds, 5], [:days, 3], [:seconds, 7]]`).
At that time the `reduce` in `#inspect` made sense,
since we would need to get the totals for each part
(the example would become `{ seconds: 12, days: 3 }`).
With the current version of `Duration` we call `to_h` on the `parts`
immediately on initialize, so now the `reduce` doesn't seem to be doing
anything meaningful.
|
|\ \
| | |
| | | |
Pluralized enum raises error when attempting to modify
|
| | | |
|
|\ \ \
| |/ /
|/| | |
rubyonrails.org has been ready for https
|
|/ / |
|
|\ \
| | |
| | | |
Allow using queue prefix with a default queue name
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes #34366
Currently setting queue_name_prefix will not combine a prefix with the
default_queue_name; it will only affect queue names set with `queue_as`.
With this PR the prefix will affect the default_queue_name as well.
Closes #19831
Currently setting default_queue_name doesn't actually affect the
queue_name default (although default_queue_name does get used if you
pass a falsey `part_name` to `queue_as`). This PR would get
default_queue_name working as expected as well.
Because the queue_name default is now a lambda wrapping the
default_queue_name, rather than the default_queue_name itself, I had to
update one test to use the instance method `#queue_name` (which
`instance_exec`s the value) instead of the class method. I think this
change is OK, since only the instance method is documented.
There was a question about whether we want a `default_queue_name`
configuration. If we want to get rid of it, I would also be happy to
open a PR for that instead. It has been around for a while now, but it
also hasn't really worked for a while now.
r? @matthewd
since you had an opinion about this before
|
|\ \ \
| | | |
| | | | |
Deliver parameterized mail with DeliveryJob
|