| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
...so it doesn't look like you *have* to use SQL strings for that case (not
anymore!). Would like to replace the SQL string example with something that
you cannot do with the "normal" query API, but I could not come up with a
short, realistic example. Suggestions welcome!
|
| |
|
|
|
|
|
| |
Using enum names in SQL strings doesn't actually work, the test was wrong (fixed
in 3dfd1ba).
|
|
|
|
|
| |
The previous edit kind of de-emphasized that, so changing it to be more explict.
(It also avoids showing it as if it's a string-keyed hash.)
|
|
|
|
|
| |
Also updated the documentation about the new ability to query them normally,
and added test to make sure they work!
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In addition to cleaning up the implementation, this allows type casting
behavior to be applied consistently everywhere. (#where for example). A
good example of this was the previous need for handling value to key
conversion in the setter, because the number had to be passed to `where`
directly. This is no longer required, since we can just pass the string
along to where. (It's left around for backwards compat)
Fixes #18387
|
|
|
|
|
|
|
| |
We added a comparison to "id", and call to `self.class.primary_key` a
*lot*. We also have performance hits from `&block` all over the place.
We skip the check in a new method, in order to avoid breaking the
behavior of `read_attribute`
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The definition of `write_attribute` in dirty checking ultimately leads
to the columns calling `type_cast` on the value to perform the
comparison. However, this is a potentially expensive computation that we
cache when it occurs in `read_attribute`. The only case that we need the
non-type-cast form is for numeric, so we pass that through as well
(something I'm looking to remove in the future).
This also reduces the number of places that manually access various
stages in an attribute's type casting lifecycle, which will aid in one
of the larger refactorings that I'm working on.
|
|
|
| |
When scanning the Enum API page I found it easy to miss that scopes are generated. Adding an example clarifies use and has more... *pop*...
|
| |
|
|
|
|
|
|
|
|
| |
The original attempt didn't really fix the problem and wasn't testing the
problematic area. This commit corrected those issues in the original commit.
Also removed the private `enum_mapping_for` method. As `defined_enums` is now a
method, this method doesn't provide much value anymore.
|
| |
|
|
|
|
| |
[ci skip]
|
|
|
|
|
|
|
|
|
| |
Dangerous name conflicts includes instance or class method conflicts
with methods defined within `ActiveRecord::Base` but not its ancestors,
as well as conflicts with methods generated by other enums on the same
class.
Fixes #13389.
|
| |
|
|
|
|
|
| |
This will make simpler to compare if the values changed in the
save_changed_attribute method.
|
| |
|
|
|
|
|
| |
To make this possible we have to override the save_changed_attribute
hook.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Example:
class Conversation < ActiveRecord::Base
enum status: [ :active, :archived ]
end
Before:
Conversation::STATUS # => { "active" => 0, "archived" => 1 }
After:
Conversation.statuses # => { "active" => 0, "archived" => 1 }
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Closes #13650, #13672
This is an alternate implementation to solve #13650. Currently form fields
contain the enum value (eg. "1"). This breaks because the setter `enum=`
expects the label (eg. "active").
ActiveRecord::Enum allows you to use labels in your application but store numbers.
We should make sure that all parts after AR are dealing with labels and not the
underlying mapping to a number.
This patch defines `_before_type_cast` on every enum column to return the label.
This method is later used to fetch the value to display in form fields.
I deliberately copied the implementation of the enum getter instead of delegating to it.
This allows you to overwrite the getter and for example return a `Value Object` but have it
still work for form fields.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, this would give an `ArgumentError`:
class Issue < ActiveRecord::Base
enum :status, [:open, :finished]
end
Issue.open.build # => ArgumentError: '0' is not a valid status
Issue.open.create # => ArgumentError: '0' is not a valid status
PR #13542 muted the error, but the issue remains. This commit fixes
the issue by allowing the enum value to be written directly via the
setter:
Issue.new.status = 0 # This now sets status to :open
Assigning a value directly via the setter like this is not part of the
documented public API, so users should not rely on this behavior.
Closes #13530.
|
|
|
|
|
| |
Add a mention about the automatic generation of scopes based on the
allowed values of the field on the enum documentation.
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the writer methods would simply check whether the passed
argument was the symbol representing the integer value of an enum field.
Therefore, it was not possible to specify the numeric value itself but
the dynamically defined scopes generate where clauses relying on this
kind of values so a chained call to a method like `find_or_initialize_by`
would trigger an `ArgumentError`.
Reference #13530
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This allows to assign both `String` and `Symbol` values to the enum
without having to call `to_sym`, which is a security problem.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Commit 6e4a810f51b9ed2468b92247ef5568cc9d6dbcc0 changed the implementation
from class_eval to define_method, but missed the access to the constant
versus the access to the constant name.
|
|
|
|
| |
https://github.com/rails/rails/commit/db41eb8a6ea88b854bf5cd11070ea4245e1639c5#commitcomment-4502683
|
| |
|
| |
|
| |
|
|
map to integers in the database, but can be queried by name
|