| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
There's no 'text to text' casting in the cast table so the feature detection fails.
|
| | |
|
| |\
| |
| | |
remove warning from `video_tag`
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This removes the following warning.
```
actionview/lib/action_view/helpers/asset_tag_helper.rb:291: warning: shadowing outer local variable - options
```
|
| |\ \
| |/
|/| |
Follow up of #25602
|
| | |
| |
| |
| | |
key length
|
| |/
|
|
|
|
|
|
|
| |
Since keys are truncated, ruby 2.4 doesn't accept keys greater than their lenghts.
keys of same value but different lenght and greater than key size of cipher, produce the same results
as reproduced at https://gist.github.com/rhenium/b81355fe816dcfae459cc5eadfc4f6f9
Since our default cipher is 'aes-256-cbc', key length for which is 32 bytes, limit the length of key being passed to Encryptor to 32 bytes.
This continues to support backwards compat with any existing signed data, already encrupted and signed with 32+ byte keys.
Also fixes the passing of this value in multiple tests.
|
| |\
| |
| | |
Update Jason Zimdars twitter
|
| | | |
|
| | |
| |
| |
| |
| | |
I consider the missing deprecation warning a bug fix from
the point of view of the 5.0.x series and forward.
|
| | |
| |
| |
| |
| |
| |
| | |
Makes it clearer why we're doing this
Add a comment to elaborate on what the undef means and move it closer
to the deprecations so it's less likely for whoever pulls the
deprecations that it should go too.
|
| |\ \
| |/
|/| |
Do not allow to_param on AC::Parameters
|
| | | |
|
| | |
| |
| |
| | |
The fact that this only includes column names is an oversight.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There are some minor changes to the point type as I had forgotten that
this will affect the behavior of `t.point` in migrations and the schema
dumper so we need to handle those as well.
I'll say this again so I can convince myself to come up with a better
structure... TYPES SHOULD NOT CARE ABOUT SCHEMA DUMPING AND WE NEED TO
BETTER SEPARATE THESE.
|
| |\ \
| | |
| | | |
use `message` that specified in argument to error message
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 3a1f6fe7b4a70bf0698b0684dd48ac712c6883b6.
This commit takes the code in a direction that I am looking to avoid.
The predicate builder should be purely concerned with AST construction
as it matters to methods like `where`. Things like case sensitivity
should continue to be handled elsewhere.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I still think that this is something that should be handled in the pg
gem, but it's not going to end up happening there so we'll do it here
instead. Once we bump to pg 0.19 we can pass the encoding to the
`encode` method instead.
This issue occurs because C has no concept of encoding (or strings,
really). The bytes that we pass here when sending the value to the
database will always be interpreted as whatever encoding the connection
is currently configured to use. That means that roundtripping to the
database will lose no information
However, after assigning we round trip through our type system without
hitting the database. The only way that we can do the "correct" thin
here would be to actually give a reference to the connection to the
array type and have it check the current value of the connection's
encoding -- which I'm strongly opposed to. We could also pass in the
encoding when it's constructed, but since that can change independently
of the type I'm not a huge fan of that either.
This feels like a reasonable middle ground, where if we have an array of
strings we simply use the encoding of the string we're given.
Fixes #26326.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This was almost every case where we are overriding `respond_to?` in a
way that mirrors a parallel implementation of `method_missing`. There is
one remaining case in Active Model that should probably do the same
thing, but had a sufficiently strange implementation that I want to
investigate it separately.
Fixes #26333.
|
| |\ \ \
| | | |
| | | | |
Make public asset use explicit
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Is this usage correct? cc/ @prathamesh-sonpatki
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Adding all those `public_*` methods is a bit heavy handed, we can change the API to instead use `public_folder: true`. Change was pretty easy since it was already implemented that way.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
We want to make it more explicit when a user wants to avoid the asset pipeline to do this we will add `public_*` methods to all path helpers. So if someone wants to use an asset that isn't maintained by the asset pipeline they can use `public_asset_path` instead of `asset_path` and letting it fall through.
The main reason for this change is the desire to raise helpful errors in the future. Right now if you typo an asset name, then we assume you intended an asset in the `public/` folder and not in the pipeline so nothing fails and the error sits silently until you realize the page didn't render correctly. We have to deprecate today so we can raise meaningful error messages in the future.
|
