| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This is a follow up to https://github.com/rails/rails/commit/07786c5e75a7b0afdf318063510af6b475e3e04c
and https://github.com/rails/rails/commit/cd2596f55e88fe659592612a793c4f4aa723c9be
|
| |
|
| |
|
|
|
|
| |
Fixes: https://github.com/rails/rails/issues/17856.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The detection of in-place changes caused a weird unexpected issue with
numericality validations. That validator (out of necessity) works on the
`_before_type_cast` version of the attribute, since on an `:integer`
type column, a non-numeric string would type cast to 0.
However, strings are mutable, and we changed strings to ensure that the
post type cast version of the attribute was a different instance than
the before type cast version (so the mutation detection can work
properly).
Even though strings are the only mutable type for which a numericality
validation makes sense, special casing strings would feel like a strange
change to make here. Instead, we can make the assumption that for all
mutable types, we should work on the post-type-cast version of the
attribute, since all cases which would return 0 for non-numeric strings
are immutable.
Fixes #17852
|
| |
|
|
|
|
|
|
|
|
| |
This fixes a regression where preloading association throws an
exception if one of the associations in the preloading hash doesn't
exist for one record.
Fixes #16070
|
|
|
|
|
|
| |
Since 3e30c5d, it started ignoring the given error message. This commit
changes the behavior of AR::RecordNotSaved#initialize so that it no
longer loses the given error message.
|
|\
| |
| | |
Correct test description for large integer test
|
| | |
|
|\ \
| | |
| | | |
Add #record attribute to RecordNotFound and RecordDestroyed exceptions.
|
| | |
| | |
| | |
| | | |
This allows these exceptions to be handled generically in conjunction with RecordInvalid.
|
|\ \ \
| | | |
| | | | |
Remove is_a? check when ignoring tables
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Technically changes the API, as it will allow any object which responds
to `===`. Personally, I think this is more flexible.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The records weren't being replaced since equality in Active Record is
defined in terms of `id` only. It is reasonable to expect that the
references would be replaced in memory, even if no queries are actually
executed. This change did not appear to affect any other parts of the
code base. I chose not to execute callbacks since we're not actually
modifying the association in a way that will be persisted.
Fixes #17730
|
| | | | |
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
Fix includes on association with a scope
|
| | | | |
| | | | |
| | | | |
| | | | | |
on the joined assoiciation
|
| | | | |
| | | | |
| | | | |
| | | | | |
See also PR: #17610
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Also checked to make sure this does not affect foreign key constraints.
(It doesn't).
Fixes #12856
Closes #14088
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Prior to this patch you'd end up with an error like:
```
ActiveRecord::RecordNotFound: Couldn't find <Model> with 'id'=<id> [WHERE (<default_scope condition>)]
```
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This makes the following changes:
* warn if `:null` is not passed to `add_timestamps`
* `timestamps` method docs link to `add_timestamps` docs
* explain where additional options go
* adjust examples to include `null: false` (to prevent deprecation warnings)
|
|\ \ \ \
| |/ / /
|/| | | |
Allow class_name option in habtm to be consistent with other association...
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It doesn't make sense for the subclass to implement this method, and not
have it on the parent. We can also DRY up the implementation of
`#lookup` to be defined in terms of fetch, which will give us a single
point of entry
|
| | | | |
|
| | | | |
|
|\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | | |
dtaniwaki/support-symbol-foreign-key-column-to-delete
Support symbol foreign key to delete
|
| | | | |
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | | |
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`
|
| | |
| | |
| | |
| | | |
Oh hey, we got to remove some code because of that!
|
| | |
| | |
| | |
| | |
| | |
| | | |
Arel handles this for us automatically. Updated tests, as BindParam is
no longer a subclass of SqlLiteral. We should remove the second argument
to substitute_at entirely, as it's no longer used
|
| | |
| | |
| | |
| | |
| | |
| | | |
If something causes the teardown block to not get run (errors,
interrupting test runs), we have to manually delete them, which is a
pain.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | |
| | | |
`Computer` class needs to be require
See #17217 for more details
|
| | | |
|
|\ \ \
| | | |
| | | | |
Fix bug found when running individual tests against #17217 after merging
|
| |/ / |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | | |
Empact/association-bind-values-not-updated-on-save
Fix that a collection proxy could be cached before the save of the owner, resulting in an invalid proxy lacking the owner’s id
Conflicts:
activerecord/CHANGELOG.md
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
resulting in an invalid proxy lacking the owner’s id.
Absent this fix calls like: owner.association.update_all to behave unexpectedly because they try to act on association objects where
owner_id is null.
more evidence here: https://gist.github.com/Empact/5865555
```
Active Record 3.2.13
-- create_table(:firms, {:force=>true})
-> 0.1371s
-- create_table(:clients, {:force=>true})
-> 0.0005s
1 clients. 1 expected.
1 clients updated. 1 expected.
```
```
Active Record 4.0.0
-- create_table(:firms, {:force=>true})
-> 0.1606s
-- create_table(:clients, {:force=>true})
-> 0.0004s
1 clients. 1 expected.
0 clients updated. 1 expected.
```
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Why are people assigning booleans to string columns? >_>
We unintentionally changed the behavior on Sqlite3 and PostgreSQL.
Boolean values should cast to the database's representation of true and
false. This is 't' and 'f' by default, and "1" and "0" on Mysql. The
implementation to make the connection adapter specific behavior is hacky
at best, and should be re-visted once we decide how we actually want to
separate the concerns related to things that should change based on the
database adapter.
That said, this isn't something I'd expect to change based on my
database adapter. We're storing a string, so the way the database
represents a boolean should be irrelevant. It also seems strange for us
to give booleans special behavior at all in string columns. Why is
`to_s` not sufficient? It's inconsistent and confusing. Perhaps we
should consider deprecating in the future.
Fixes #17571
|
| | | |
|
| | |
| | |
| | |
| | | |
fixes #17495
|
| | |
| | |
| | |
| | |
| | |
| | | |
if you specify a default scope on a model, it will break caching. We
cannot predict what will happen inside the scope, so play it safe for
now. fixes #17495
|
| | | |
|
| | | |
|