| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |/ / / / / |
|
|\ \ \ \ \ \
| |/ / / / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | | |
Print out a meaningful error when ActiveRecord::ReadOnlyRecord is raised
|
|/ / / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Currently, there is no messages which get printed out. Convoluted system
may have hooks that create other objects in which case we only fail with
no messages. This commit changes this information allowing you to know
which object is the one that actually raised the error.
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This makes debugging the generated schema output much easier.
As a side effect it also shaves off 2.5 seconds of test runtime.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | | |
copy reflection_scopes’s unscoped value when building scope for preloading
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
preloading, fixes #11036
|
| | | | | | | |
|
| | | | | | | |
|
| |_|/ / / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | | |
We should not behave differently just because a class has a default
scope.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We support this behavior, but have no tests which assert that type
casting actually occurs.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
It was transitively relying on the vertex model being loaded
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
In practical terms, this allows serialized columns and tz aware columns
to be used in wheres that go through joins, where they previously would
not behave correctly. Internally, this removes 1/3 of the cases where we
rely on Arel to perform type casting for us.
There were two non-obvious changes required for this. `update_all` on
relation was merging its bind values with arel's in the wrong order.
Additionally, through associations were assuming there would be no bind
parameters in the preloader (presumably because the where would always
be part of a join)
[Melanie Gilman & Sean Griffin]
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Nothing is directly using the columns for the default values anymore.
This step helps us get closer not not mutating the columns hash.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Fixes #17170
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
ziggythehamster/activerecord-connectionhandling-RAILS_ENV-without-rails
If Rails is not defined, check ENV["RAILS_ENV"] and ENV["RACK_ENV"] in ActiveRecord::ConnectionHandling
|
| |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This fixes a regression introduced by 6cc03675d30b58e28f585720dad14e947a57ff5b.
ActiveRecord, if used without Rails, always checks the "default_env" environment. This would be OK, except that Sinatra also supports environments,
and it runs with {RACK|RAILS}_ENV=production. This patch adds a fallback to RAILS_ENV and RACK_ENV (and ultimately default_env) if Rails.env doesn't exist.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We had accidentally gone one power of two too far. In addition, we need
to handle minimum values as well as the maximum.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Sufficiently large integers cause `find` and `find_by` to raise
`StatementInvalid` instead of `RecordNotFound` or just returning `nil`.
Given that we can't cast to `nil` for `Integer` like we would with junk
data for other types, we raise a `RangeError` instead, and rescue in
places where it would be highly unexpected to get an exception from
casting.
Fixes #17380
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Arel has changed so that `.sum` no longer aliases `SUM(the_column)` to
`sum_id`. This means the type returned by the adapter will be at the key
`"SUM(the_column)"`. Longer term, we should eventually be able to retain
type information from the AR::Base subclasses used in joined queries
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The MySQLAdapter type map used the lowest priority for enum types.
This was the result of a recent refactoring and lead to some broken lookups
for enums with values that match other types. Like `8bit`.
This patch restores the priority to what we had before the refactoring.
/cc @sgrif
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We were relying on hash inequality in tests
|
| | | | | | |
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | | |
Raises ArgumentError when try to define a scope without a callable
|
| |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This changes the actual exception `NoMethodError: undefined method `call'
for #<ActiveRecord::Relation []>` to a `ArgumentError` when try to define
a scope without a callable.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Use type column first in multi-column indexes
Conflicts:
activerecord/CHANGELOG.md
|
| |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
`add_reference` can very helpfully add a multi-column index when you use
it to add a polymorphic reference. However, the first column in the
index is the `id` column, which is less than ideal.
The [PostgreSQL docs][1] say:
> A multicolumn B-tree index can be used with query conditions that
> involve any subset of the index's columns, but the index is most
> efficient when there are constraints on the leading (leftmost)
> columns.
The [MySQL docs][2] say:
> MySQL can use multiple-column indexes for queries that test all the
> columns in the index, or queries that test just the first column, the
> first two columns, the first three columns, and so on. If you specify
> the columns in the right order in the index definition, a single
> composite index can speed up several kinds of queries on the same
> table.
In a polymorphic relationship, the type column is much more likely to be
useful as the first column in an index than the id column. That is, I'm
more likely to query on type without an id than I am to query on id
without a type.
[1]: http://www.postgresql.org/docs/9.3/static/indexes-multicolumn.html
[2]: http://dev.mysql.com/doc/refman/5.0/en/multiple-column-indexes.html
|
|/ / / / / |
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
Message on AR::UnknownAttributeError should include the class name of a record
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This would be helpful if 2 models have an attribute that has a similar
name to the other. e.g:
before:
User.new(name: "Yuki Nishijima", projects_attributes: [name: "kaminari"])
# => ActiveRecord::UnknownAttributeError: unknown attribute: name
after:
User.new(name: "Yuki Nishijima", projects_attributes: [name: "kaminari"])
# => ActiveRecord::UnknownAttributeError: unknown attribute on User: name
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This would be helpful if 2 models have an attribute that has a similar
name to the other. e.g:
before:
User.new(name: "Yuki Nishijima", projects_attributes: [name: "kaminari"])
# => ActiveRecord::UnknownAttributeError: unknown attribute: name
after:
User.new(name: "Yuki Nishijima", projects_attributes: [name: "kaminari"])
# => ActiveRecord::UnknownAttributeError: unknown attribute on User: name
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
claudiob/replace-slower-block-call-with-faster-yield
Replace (slower) block.call with (faster) yield
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This reverts commit 0ab075e75f58bf403f7ebe20546c7005f35db1f6.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Performance optimization: `yield` with an implicit `block` is faster than `block.call`.
See http://youtu.be/fGFM_UrSp70?t=10m35s and the following benchmark:
```ruby
require 'benchmark/ips'
def fast
yield
end
def slow(&block)
block.call
end
Benchmark.ips do |x|
x.report('fast') { fast{} }
x.report('slow') { slow{} }
end
# => fast 154095 i/100ms
# => slow 71454 i/100ms
# =>
# => fast 7511067.8 (±5.0%) i/s - 37445085 in 4.999660s
# => slow 1227576.9 (±6.8%) i/s - 6145044 in 5.028356s
```
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
In Rails 5.0, we'd like to change the behavior of boolean columns in
Rails to be closer to Ruby's semantics. Currently we have a small set
of values which are "truthy", and all others are "falsy". In Rails 5.0,
we will reverse this to have a small number of values which are "falsy",
and all others will become "truthy".
In the interim, all values which are ambiguous must emit a deprecation
warning.
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The behavior has changed since 4.1 and non-array values are no
longer type casted to a blank array. This way the user can define
custom validations on that property.
|