| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
ActiveModel::Type)
Some code was previously referring to ActiveModel::Type::*. This could
cause issues in the future if any of the ActiveRecord::Type classes were
overridden in the future.
|
|
|
|
|
|
| |
Test: JSON attribute value nil can be used in where(attr: nil)
Add changelog entry
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we were assuming that the only valid types for encoding were
arrays and hashes. However, any JSON primitive is an accepted value by
both PG and MySQL.
This does involve a minor breaking change in the handling of `default`
in the schema dumper. This is easily worked around, as passing a
hash/array literal would have worked fine in previous versions of Rails.
However, because of this, I will not be backporting this to 4.2 or
earlier.
Fixes #24234
|
|
|
|
|
|
|
| |
We do not need to require each file from AM individually, the type
module does that for us. Even if the classes are extremely small right
now, I'd rather keep any custom classes needed by AR in their own files,
as they can easily have more complex changes in the future.
|
|
|
|
| |
The first step of bringing typecasting to ActiveModel
|
|
Several changes were made in #21110 which I am strongly opposed to.
(this is what I get for going on vacation. :trollface:) No type should
be introduced into the generic `ActiveRecord::Type` namespace, and
*certainly* should not be registered into the registry unconstrained
unless it is supported by *all* adapters (which basically means that it
was specified in the ANSI SQL standard).
I do not think `# :nodoc:` ing the type is sufficient, as it still makes
the code of Rails itself very unclear as to what the role of that class
is. While I would argue that this shouldn't even be a super class, and
that MySql and PG's JSON types are only superficially duplicated (they
might look the same but will change for different reasons in the
future).
However, I don't feel strongly enough about it as a point of contention
(and the biggest cost of harming the blameability has already occured),
so I simply moved the superclass into a namespace where its role is
absolutely clear.
After this change, `attribute :foo, :json` will once again work with
MySQL and PG, but not with Sqlite3 or any third party adapters.
Unresolved questions
--------------------
The types that and adapter publishes (at least those are unique to that
adapter, and not adding additional behavior like `MysqlString` should
probably be part of the adapter's public API. Should we standardize the
namespace for these, and document them?
|