| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
And enable `context_dependent` of Style/BracesAroundHashParameters cop.
|
| | |
|
| |
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
| |
|
|
|
|
|
| |
Any gems or libraries which do work with serialization or YAML will
ultimately need to compare these objects (albeit indirectly) to ensure
correctness. These will likely never get used internally (as they're
slow), but we should still expose them for others.
|
| |
|
|
|
|
|
|
|
|
|
| |
I'm looking to move towards a tree-like structure for dirty checking
that involves an attribute holding onto the attribute that it was
created from. This means that `changed?` can be fully encapsulated on
that object. Since the objects are immutable, in `changes_applied`, we
can simply perform a shallow dup, instead of a deep one.
I'm not sure if that will actually end up in a performance boost, but
I'd like to semantically separate these concepts regardless
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This moves a bit more of the logic required for dirty checking into the
attribute objects. I had hoped to remove the `with_value_from_database`
stuff, but unfortunately just calling `dup` on the attribute objects
isn't enough, since the values might contain deeply nested data
structures. I think this can be cleaned up further.
This makes most dirty checking become lazy, and reduces the number of
object allocations and amount of CPU time when assigning a value. This
opens the door (but doesn't quite finish) to improving the performance
of writes to a place comparable to 4.1
|
| | |
|
| | |
|
| |
|
|
| |
Fixes #18871
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This method can be used to see all of the fields on a model which have
been read. This can be useful during development mode to quickly find
out which fields need to be selected. For performance critical pages, if
you are not using all of the fields of a database, an easy performance
win is only selecting the fields which you need. By calling this method
at the end of a controller action, it's easy to determine which fields
need to be selected.
While writing this, I also noticed a place for an easy performance win
internally which I had been wanting to introduce. You cannot mutate a
field which you have not read. Therefore, we can skip the calculation of
in place changes if we have never read from the field. This can
significantly speed up methods like `#changed?` if any of the fields
have an expensive mutable type (like `serialize`)
```
Calculating -------------------------------------
#changed? with serialized column (before)
391.000 i/100ms
#changed? with serialized column (after)
1.514k i/100ms
-------------------------------------------------
#changed? with serialized column (before)
4.243k (± 3.7%) i/s - 21.505k
#changed? with serialized column (after)
16.789k (± 3.2%) i/s - 84.784k
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`freeze` will ultimately end up freezing the `AttributeSet`, which in
turn freezes its `@attributes` hash. However, we actually insert a
special object to lazily instantiate the values of the hash on demand.
When it does need to actually instantiate all of them for iteration (the
only case is `ActiveRecord::Base#attributes`, which calls
`AttributeSet#to_h`), it will set an instance variable as a performance
optimization
Since it's just an optimization for subsequent calls, and that method
being called at all is a very uncommon case, we can just leave the ivar
alone if we're frozen, as opposed to coming up with some overly
complicated mechanism for freezing which allows us to continue to modify
ourselves.
Fixes #17960
|
| |
|
|
|
|
|
| |
In real usage, we give the builder a types hash with a default value of
`Type::Value.new`. This means we need to explicitly check for the key,
rather than the truthiness of the type to determine if it's a known but
uninitialized attribute
|
| |
|
|
|
|
|
|
|
|
| |
We don't know which attributes will or won't be used, and we don't want
to create massive bottlenecks at instantiation. Rather than doing *any*
iteration over types and values, we can lazily instantiate the object.
The lazy attribute hash should not fully implement hash, or subclass
hash at any point in the future. It is not meant to be a replacement,
but instead implement its own interface which happens to overlap.
|
| |
|
|
| |
https://github.com/rails/rails/pull/15868/files#r14135210
|
| |
|
|
|
| |
This allows using polymorphism for the uninitialized attributes raising
an exception behavior.
|
| |
|
|
|
|
|
|
| |
This will make it less painful to add additional properties, which
should persist across writes, such as `name`.
Conflicts:
activerecord/lib/active_record/attribute_set.rb
|
| |\
| |
| |
| |
| |
| |
| |
| | |
Move behavior of `read_attribute` to `AttributeSet`
Conflicts:
activerecord/lib/active_record/attribute_set.rb
activerecord/test/cases/attribute_set_test.rb
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Moved `Builder` to its own file, as it started looking very weird once I
added private methods to the `AttributeSet` class and the `Builder`
class started to grow.
Would like to refactor `fetch_value` to change to
```ruby
self[name].value(&block)
```
But that requires the attributes to know about their name, which they
currently do not.
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| | |
Move `attributes_before_type_cast` to `AttributeSet`
Conflicts:
activerecord/lib/active_record/attribute_set.rb
activerecord/test/cases/attribute_set_test.rb
|
| | | |
|
| |\ \
| | |
| | | |
Return a null object from `AttributeSet#[]`
|
| | |/ |
|
| |/ |
|
|
|
Mostly delegation to start, but we can start moving a lot of behavior in
bulk to this object.
|
