| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|/ /
| |
| |
| |
| |
| | |
We only add the header when releasing to avoid some conflicts.
[ci skip]
|
|\ \
| | |
| | |
| | |
| | |
| | | |
yujideveloper/feature/delegate-ar-base-pick-to-all
Add `delegate :pick, to: :all`
|
|/ / |
|
| |
| |
| |
| | |
This reverts commit a19e91f0fab13cca61acdb1f33e27be2323b9786.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a class has a belongs_to or has_one relationship with dependent: :destroy
option enabled, objects of this class should not be deleted if it's dependents
cannot be deleted.
Example:
class Parent
has_one :child, dependent: :destroy
end
class Child
belongs_to :parent, inverse_of: :child
before_destroy { throw :abort }
end
c = Child.create
p = Parent.create(child: c)
p.destroy
p.destroyed? # expected: false; actual: true;
Fixes #32022
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
locking is enabled
This issue is caused by `@_trigger_update_callback` won't be updated due
to `_update_record` in `Locking::Optimistic` doesn't call `super` when
optimistic locking is enabled.
Now optimistic locking concern when updating is supported by
`_update_row` low level API, therefore overriding `_update_record` is no
longer necessary.
Removing the method just fix the issue.
Closes #29096.
Closes #29321.
Closes #30823.
|
|
|
|
| |
`Persistence` module
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently primary key value can not be updated if a record has a locking
column because of `_update_record` in `Locking::Optimistic` doesn't
respect `id_in_database` as primary key value unlike in `Persistence`.
And also, if a record has dirty primary key value, it may destroy any
other record by the lock version of dirty record itself.
When updating/destroying persisted records, it should identify
themselves by `id_in_database`, not by dirty primary key value.
|
|\
| |
| | |
Fix occurrences Fixnum|Bignum
|
| |
| |
| |
| | |
Related to https://github.com/rails/rails/commit/d4eb0dc89ee6b476e2e10869dc282a96f956c6c7#r27830891
|
|/
|
|
|
| |
This removes `|| id` which were added in #9963 and #23887 since it is no
longer necessary.
|
|
|
|
|
|
|
|
|
|
| |
This reverts ignoring polymorphic error introduced at 02da8ae.
What the ignoring want to solve was caused by force eager loading
regardless of whether it is necessary, but it has been fixed by #29043.
The ignoring is now only causing a mismatch of `exists?` behavior with
`to_a`, `count`, etc. It should behave consistently.
|
|
|
|
|
|
|
| |
This is an alternative of #29722, and follow up of #32048.
This does not change the current behavior, but makes it easier to modify
all polymorphic names consistently.
|
|
|
|
|
| |
Ruby 2.4+ provides `Hash#compact` and `Hash#compact!` natively,
so `active_support/core_ext/hash/compact` is no longer necessary.
|
|
|
|
| |
Since Rails 6 requires Ruby 2.4.1+.
|
|
|
|
|
| |
https://bugs.ruby-lang.org/issues/12752
https://ruby-doc.org/core-2.4.0/String.html#method-i-unpack1
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This comment was added at 070dda2. That arguments has already been
changed since those are internal nodoc classes, but the comment does not
reflect the current state.
I decided to remove the staled comment since it is not useful for
understanding what the class does.
[ci skip]
|
|
|
|
|
|
| |
Follow up of b988ecb99ff6c8854e4b74ef8a7ade8d9ef5d954.
This was added for internal usage, it doesn't need to be public.
|
|
|
|
| |
Duplicated method name list is no longer needed.
|
| |
|
|
|
|
| |
There is no reason `attributes=` doesn't take `assign_attributes`.
|
|
|
|
| |
This was added in 9bfa13b, but it is never used from the beginning.
|
|
|
|
| |
columsn ->
columns
|
|\
| |
| |
| |
| | |
Expand AR::Base.abstract_class documentation
[ci skip]
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The previous documentation is somewhat unclear about the use case for an
abstract ActiveRecord class.
This clears it up by highlighting the following points:
- table_name is not derived from the abstract class' name
- type is not derived on direct descendants of the abstract class
- validations, not abstract_class, should be used to specify whether
the parent model can be instantiated or not
|
| |
| |
| |
| | |
Related to 948b931925febac3c965ab13470065ced68f7b53
|
|\ \
| | |
| | |
| | | |
Use column alias of primary_key in limited_ids_for
|
|/ /
| |
| |
| |
| |
| |
| | |
Prevent `ActiveRecord::FinderMethods#limited_ids_for` from using correct primary
key values even if `ORDER BY` columns include other table's primary key.
Fixes #28364.
|
|\ \
| | |
| | |
| | | |
Active Record distinct & order #count regression
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
tgxworld/raise_error_when_advisory_lock_is_not_releases
Raise an error if advisory lock in migrator was not released.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Actually `reflection.klass` should be valid AR model unless
`polymorphic?`. Previously it worked limitedly by ignoring `NameError`
even if `reflection.klass` is invalid, and our isolated testing depends
on the limited working.
Probably we should also check the klass validity in `check_validity!`
properly. Until that time, I restored the error suppression for now.
Closes #32113.
|
| | | |
| | | |
| | | |
| | | | |
See 948b931925febac3c965ab13470065ced68f7b53 for context
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Currently the place where we limit what gets sent to the database is in
the implementation for `partial_writes`. We should also be restricting
it to column names when partial writes are turned off.
Note that we're using `&` instead of just defaulting to
`self.class.column_names`, as the instance version of `attribute_names`
does not include attributes which are uninitialized (were not included
in the select clause)
|
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | | |
Since #31895, build of 2.5 and AR combination failed.
https://travis-ci.org/rails/rails/jobs/346064349#L1638
It seems to be the reason that model is not loading properly, so I added
require. But I'm not sure if this is correct
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
kamipo/do_not_attempt_to_find_inverse_of_polymorphic
Make `reflection.klass` raise if `polymorphic?` not to be misused
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
`belongs_to` association
We can't automatically find the inverse of a polymorphic `belongs_to`
association without context.
[Ryuta Kamizono & Eric K Idema]
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is an alternative of #31877 to fix #31876 caused by #28808.
This issue was caused by a combination of several loose implementation.
* finding automatic inverse association of polymorphic without context (caused by #28808)
* returning `klass` even if `polymorphic?` (exists before #28808)
* loose verification by `valid_inverse_reflection?` (exists before #28808)
This makes `klass` raise if `polymorphic?` not to be misused.
This issue will not happen unless polymorphic `klass` is misused.
Fixes #31876.
Closes #31877.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is an alternative of #29722, and revert of #29601 and a1fcbd9.
Currently, association creation and normal association finding doesn't
respect `store_full_sti_class`. But eager loading and preloading respect
the setting. This means that if set `store_full_sti_class = false`
(`true` by default), eager loading and preloading can not find
created polymorphic records.
Association creation and finding should work consistently.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
* Add test case for open-ended range.
* Add test case for numeric range for string column.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
BC dates are supported by both date and datetime types.
https://www.postgresql.org/docs/current/static/datatype-datetime.html
Since #1097, new datetime allows year zero as 1 BC, but new date does
not. It should be allowed even in new date consistently.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The values infinity and -infinity are supported by both date and
timestamp types.
https://www.postgresql.org/docs/current/static/datatype-datetime.html#DATATYPE-DATETIME-SPECIAL-TABLE
And also, it can not be known whether a value is infinity correctly
unless cast a value.
I've added `QueryAttribute#infinity?` to handle that case.
Closes #27585.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Since #32028, Rails 6 requires Ruby 2.3+.
No longer needed workaround for Ruby 2.2 "private attribute?" warning.
|