| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As a result of all of the refactoring that's been done, it's now
possible for us to define a public API to allow users to specify
behavior. This is an initial implementation so that I can work off of it
in smaller pieces for additional features/refactorings.
The current behavior will continue to stay the same, though I'd like to
refactor towards the automatic schema detection being built off of this
API, and add the ability to opt out of automatic schema detection.
Use cases:
- We can deprecate a lot of the edge cases around types, now that there
is an alternate path for users who wish to maintain the same behavior.
- I intend to refactor serialized columns to be built on top of this
API.
- Gem and library maintainers are able to interact with `ActiveRecord`
at a slightly lower level in a more stable way.
- Interesting ability to reverse the work flow of adding to the schema.
Model can become the single source of truth for the structure. We can
compare that to what the database says the schema is, diff them, and
generate a migration.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* * *
This bug can be triggered when serializing record R (the instance) of type C
(the class), provided that the following conditions are met:
1. The name of one or more columns/attributes on C/R matches an existing private
method on C (e.g. those defined by `Kernel`, such as `format`).
2. The attribute methods have not yet been generated on C.
In this case, the matching private methods will be called by the serialization
code (with no arguments) and their return values will be serialized instead. If
the method requires one or more arguments, it will result in an `ArgumentError`.
This regression is introduced in d1316bb.
* * *
Attribute methods (e.g. `#name` and `#format`, assuming the class has columns
named `name` and `format` in its database table) are lazily defined. Instead of
defining them when a the class is defined (e.g. in the `inherited` hook on
`ActiveRecord::Base`), this operation is deferred until they are first accessed.
The reason behind this is that is defining those methods requires knowing what
columns are defined on the database table, which usually requires a round-trip
to the database. Deferring their definition until the last-possible moment helps
reducing unnessary work, especially in development mode where classes are
redefined and throw away between requests.
Typically, when an attribute is first accessed (e.g. `a_book.format`), it will
fire the `method_missing` hook on the class, which triggers the definition of
the attribute methods. This even works for methods like `format`, because
calling a private method with an explicit receiver will also trigger that hook.
Unfortunately, `read_attribute_for_serialization` is simply an alias to `send`,
which does not respect method visibility. As a result, when serializing a record
with those conflicting attributes, the `method_missing` is not fired, and as a
result the attribute methods are not defined one would expected.
Before d1316bb, this is negated by the fact that calling the `run_callbacks`
method will also trigger a call to `respond_to?`, which is another trigger point
for the class to define its attribute methods. Therefore, when Active Record
tries to run the `after_find` callbacks, it will also define all the attribute
methods thus masking the problem.
* * *
The proper fix for this problem is probably to restrict `read_attribute_for_serialization`
to call public methods only (i.e. alias `read_attribute_for_serialization` to
`public_send` instead of `send`). This however would be quite risky to change
in a patch release and would probably require a full deprecation cycle.
Another approach would be to override `read_attribute_for_serialization` inside
Active Record to force the definition of attribute methods:
def read_attribute_for_serialization(attribute)
self.class.define_attribute_methods
send(attribute)
end
Unfortunately, this is quite likely going to cause a performance degradation.
This patch therefore restores the behaviour from the 4-0-stable branch by
explicitly forcing the class to define its attribute methods in a similar spot
(when records are initialized). This should not cause any extra roundtrips to
the database because the `@columns` should already be cached on the class.
Fixes #15188.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 9a1abedcdeecd9464668695d4f9c1d55a2fd9332, reversing
changes made to c72d6c91a7c0c2dc81cc857a1d6db496e84e0065.
Conflicts:
activerecord/CHANGELOG.md
activerecord/test/models/comment.rb
This change break integration with activerecord-deprecated_finders so
I'm reverting until we find a way to make it work with this gem.
|
|
|
|
|
|
|
|
|
| |
The foreign_key could be `String` and just doing `owners_map[owner_key]`
could return `nil`.
To prevent this bug, we should `to_s` both keys if their types are
different.
Fixes #14734.
|
|\
| |
| |
| |
| |
| |
| | |
Fixes Issue #13466.
Conflicts:
activerecord/CHANGELOG.md
|
| |
| |
| |
| |
| |
| | |
Changed the call to a scope block to be evaluated with instance_eval.
The result is that ScopeRegistry can use the actual class instead of base_class when
caching scopes so queries made by classes with a common ancestor won't leak scopes.
|
| | |
|
| |
| |
| |
| |
| |
| | |
Thank's for @laurocaetano for the help with tests. :smiley:
Fixes #14709
|
|\ \
| | |
| | |
| | |
| | |
| | | |
Conflicts:
activerecord/CHANGELOG.md
activesupport/CHANGELOG.md
|
| |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
PostgreSQL, remove varchar limit.
Conflicts:
activerecord/CHANGELOG.md
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
& Yves Senn]
There is no reason for the PG adapter to have a default limit of 255 on :string
columns. See this snippet from the PG docs:
Tip: There is no performance difference among these three types, apart
from increased storage space when using the blank-padded type, and a
few extra CPU cycles to check the length when storing into a
length-constrained column. While character(n) has performance
advantages in some other database systems, there is no such advantage
in PostgreSQL; in fact character(n) is usually the slowest of the
three because of its additional storage costs. In most situations text
or character varying should be used instead.
|
| |/ / |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Auto-generate stable fixture UUIDs on PostgreSQL
Conflicts:
activerecord/CHANGELOG.md
activerecord/lib/active_record/fixtures.rb
activerecord/test/cases/adapters/postgresql/uuid_test.rb
activesupport/CHANGELOG.md
|
| | |
| | |
| | |
| | | |
Fixes: #11524
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It was causing error when using `with_options` passing a lambda as its
last argument.
class User < ActiveRecord::Base
with_options dependent: :destroy do |assoc|
assoc.has_many :profiles, -> { where(active: true) }
end
end
It was happening because the `option_merger` was taking the last
argument and checking if it was a Hash. This breaks the HasMany usage,
because its last argument can be a Hash or a Proc.
As the behavior described in this test:
https://github.com/rails/rails/blob/master/activesupport/test/option_merger_test.rb#L69
the method will only accept the lambda, this way it will keep the expected behavior. See 9eaa0a34
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
conflicting private method defined on its ancestors.
The problem is that `method_defined_within?(name, klass, superklass)`
only works correclty when `klass` and `superklass` are both `Class`es.
If both `klass` and `superklass` are both `Class`es, they share the
same inheritance chain, so if a method is defined on `klass` but not
`superklass`, this method must be introduced at some point between
`klass` and `superklass`.
This does not work when `superklass` is a `Module`. A `Module`'s
inheritance chain contains just itself. So if a method is defined on
`klass` but not on `superklass`, the method could still be defined
somewhere upstream, e.g. in `Object`.
This fix works by avoiding calling `method_defined_within?` with a
module while still fufilling the requirement (checking that the
method is defined withing `superclass` but not is not a generated
attribute method).
4d8ee288 is likely an attempted partial fix for this problem. This
unrolls that fix and properly check the `superclass` as intended.
Fixes #11569.
|
| | |
|
|/
|
|
|
|
|
| |
The `subclass_from_attrs` method is called even if the column specified by
the `inheritance_column` setting doesn't exist. This prevents setting associations
via the attributes hash if the association name clashes with the value of the setting,
typically `:type`. This worked previously in Rails 3.2.
|
|
|
|
|
|
|
|
|
|
| |
Renaming the test accordingly to its behaviour
Adding 'Fixes' statement to changelog
Improving tests legibility & changelog
Undoing mistakenly removed empty line & further improving changelog
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The dynamic finder was creating the method signature with the parameters name,
which may have reserved words and this way creating invalid Ruby code.
Closes: #13261
Example:
# Before
Dog.find_by_alias('dog name')
# Was creating this method
def self.find_by_alias(alias, options = {})
# After
Dog.find_by_alias('dog name')
# Will create this method
def self.find_by_alias(_alias, options = {})
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
map to integers in the database, but can be queried by name
|
|
|
|
|
|
|
|
|
|
|
| |
Currently `scope_chain` uses same array for building different
`scope_chain` for different associations. During processing
these arrays are sometimes mutated and because of in-place
mutation the changed `scope_chain` impacts other reflections.
Fix is to dup the value before adding to the `scope_chain`.
Fixes #3882.
|
| |
|
| |
|
|
|
|
|
|
|
| |
According to
https://github.com/rails/rails/blob/b601399b72ab56cc01368f02615af99f45d1
4f02/activerecord/lib/active_record/counter_cache.rb#L14, u can pass
more then one association to the `reset_counters` method.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
PR #5210 added a Friendship model to illustrate a bug, but in doing so
created a confusing structure because both belongs_to declarations in
Friendship referred to the same side of the join. The new structure
maintains the integrity of the bug test while changing the follower
relationship to be more useful for other testing.
|
|\
| |
| | |
test case for `serialize` default values.
|
| |
| |
| |
| | |
Closes #9110
|
|\ \
| |/
|/|
| |
| |
| |
| | |
cache_key consults updated_on timestamp if present
Conflicts:
activerecord/CHANGELOG.md
|
| |
| |
| |
| |
| | |
- Extract max timestamp retrieval for cache_key
- Update changelog for cache_key changes
|
|/
|
|
|
| |
This reverts commit 408227d9c5ed7de26310d72a1a99c1ee02311c63, reversing
changes made to dca0b57d03deffc933763482e615c3cf0b9a1d97.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This caused a bug with the new associations implementation, because now
association conditions are represented as Arel nodes internally right up
to when the whole thing gets turned to SQL.
In Rails 3.2, association conditions get turned to raw SQL early on,
which prevents Relation#merge from interfering.
The current implementation was buggy when a default_scope existed on the
target model, since we would basically end up doing:
default_scope.merge(association_scope)
If default_scope contained a where(foo: 'a') and association_scope
contained a where(foo: 'b').where(foo: 'c') then the merger would see
that the same column is representated on both sides of the merge and
collapse the wheres to all but the last: where(foo: 'c')
Now, the RHS of the merge is left alone.
Fixes #8990
|
|
|
|
| |
Fix #8575
|
|
|
|
|
|
| |
Conflicts:
activerecord/test/models/bulb.rb
activerecord/test/schema/schema.rb
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In the end I think the pain of implementing this seamlessly was not
worth the gain provided.
The intention was that it would allow plain ruby objects that might not
live in your main application to be subclassed and have persistence
mixed in. But I've decided that the benefit of doing that is not worth
the amount of complexity that the implementation introduced.
|
|
|
|
|
| |
The counter column name in the intermediate model need to be access
via the through reflection.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allows you to specify the model association key in a belongs_to
relationship instead of the foreign key.
The following queries are now equivalent:
Post.where(:author_id => Author.first)
Post.where(:author => Author.first)
PriceEstimate.where(:estimate_of_type => 'Treasure', :estimate_of_id => treasure)
PriceEstimate.where(:estimate_of => treasure)
|
| |
|