| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
| |
The type code is actually quite accessible, and I'm planning to
encourage people to look at the files in the `type` folder to learn more
about how it works. This will help reduce the noise from code that is
less about type casting, and more about random AR nonsense.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Adding `# :nodoc:` to the parent `class` / `module` is not going
to ignore nested classes or modules.
There is a modifier `# :nodoc: all` but sadly the containing class
or module will continue to be in the docs.
/cc @sgrif
|
|
|
|
|
|
| |
We have several mutable types on Active Record now. (Serialized, JSON,
HStore). We need to be able to detect if these have been modified in
place.
|
|
|
|
|
|
|
|
| |
In some cases there is a difference between the two, we should always
be doing one or the other. For convenience, `type_cast` is still a
private method on type, so new types that do not need different behavior
don't need to implement two methods, but it has been moved to private so
it cannot be used accidentally.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- The following is now true for all types, all the time
- `model.attribute_before_type_cast == given_value`
- `model.attribute == model.save_and_reload.attribute`
- `model.attribute == model.dup.attribute`
- `model.attribute == YAML.load(YAML.dump(model)).attribute`
- Removes the remaining types implementing `type_cast_for_write`
- Simplifies the implementation of time zone aware attributes
- Brings tz aware attributes closer to being implemented as an attribute
decorator
- Adds additional point of control for custom types
|
|
|
|
|
| |
`@raw_attributes` should not contain the type-cast, mutable version of
the value.
|
|
|
|
|
|
|
|
|
|
|
| |
The solution presented in this patch is not efficient. We should replace it
in the near future. The following needs to be worked out:
* Is `@attributes` storing the Ruby or SQL representation?
* `cacheable_column?` is broken but `hstore` and `json` rely on that behavior
Refs #15369.
/cc @sgrif @rafaelfranca
|
|
As we promote these classes to first class concepts, these classes are
starting to gain enough behavior to warrant being moved into their own
files. Many of them will become quite large as we move additional
behavior to the type objects.
|