| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
| | |
| | |
| | | |
We were relying on hash inequality in tests
|
| | |
| | |
| | |
| | |
| | |
| | | |
The query cache uses bind values as hash keys. The current
implementation relies on reference equality for hash equality. This is
brittle, and can easily break in the future.
|
| | |
| | |
| | |
| | | |
We shouldn't rely on reference equality of these objects in tests
|
| | |
| | |
| | |
| | | |
The value methods will default to an empty array for us automatically
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
The change to accessing keys directly was originally added to allow
`merge` to take a hash. The implementation of `HashMerger` no longer
requires us to be doing so. Accessing the values directly makes it
impossible to change internal storage details, even if shim methods are
added temporarily
|
| | |
|
|\ \
| | |
| | |
| | | |
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
|
|\ \
| | |
| | | |
Fix Relation#rewhere to work with Range values
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
This will avoid naming clash with user defined methods
|
| |/
|/|
| |
| | |
[ci skip]
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `select` method has the same definition in almost all database
adapters, so it can be moved from the database-specific adapters
(PostgreSQl, MySQL, SQLite) to the abstract `database_statement`:
```ruby
def select(sql, name = nil, binds = [])
exec_query(sql, name, binds)
end
```
---
More details about this commit: the only two DB-specific adapters
that have a different definition of `select` are MySQLAdapter and
MySQL2Adapter.
In MySQLAdapter, `select` invokes `exec_query(sql, name, binds)`, so
calling `super` achieves the same goal with less repetition.
In MySQL2Adapter, `select` invokes `exec_query(sql, name)`, that is,
it does not pass the `binds` parameter like other methods do. However,
[MySQL2Adapter's `exec_query`](https://github.com/rails/rails/blob/74a527cc63ef56f3d0a42cf638299958dc7cb08c/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb#L228L231)
works exactly the same whether this parameters is passed or not, so the output
does not change:
```ruby
def exec_query(sql, name = 'SQL', binds = [])
result = execute(sql, name)
ActiveRecord::Result.new(result.fields, result.to_a)
end
```
|
|\
| |
| |
| | |
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.
|
| |
| |
| |
| | |
/cc @sgrif
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
| |
In the DSL you can now do:
create_table(:foos) do |t|
t.bigint :hi
end
|
| |
|
|\
| |
| |
| | |
Raise an error for has_one associations which try to go :through a polymorphic association
|
| |
| |
| |
| | |
polymorphic association [#17263]
|
|/ |
|
|
|
| |
The intention here is to make the required config copy-able from the console/logs, so add a newline at the end of the message to make that easier. (Otherwise it would be `... raise_in_transactional_callbacks = true (called from...`.)
|
| |
|
|
|
|
| |
follow up for #17052
|
|
|
|
|
| |
For now, we don't want to take "scoping" calls in to account when
calculating cache keys for relations, so just opt-out.
|
|
|
|
|
|
|
|
|
| |
This clarify the fact that `#update_all` doesn't type-cast passed
values and that these values are written as-is in the SQL DB.
Fix #17242
[ci skip]
|
|\
| |
| | |
Remove duplicate error message "Couldn't find..."
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit removes the duplication of the error message:
> Couldn't find #{@klass.name} with [#{arel.where_sql}]
introduced in #15791 by adding a private method `find_nth!` that
deals with all the method like `first!` and `second!`.
|
| |
| |
| |
| |
| | |
emit an event when we instantiate AR objects so we can see how many
records were instantiated and how long it took
|
| | |
|
|\ \
| | |
| | | |
Autosave callbacks shouldn't be `after_save` callbacks
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
068f092ced8483e557725542dd919ab7c516e567 registered autosave callbacks
as `after_save` callbacks. This caused the regression described in #17209.
Autosave callbacks should be registered as `after_update` and
`after_create` callbacks, just like before.
This is a partial revert of 068f092ced8483e557725542dd919ab7c516e567.
Fixes #17209.
|
|/ / |
|
|\ \
| |/
|/| |
speed up fixtures by not loading all their classes
|