| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| | |
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
|
| |/
|
|
| |
This will avoid naming clash with user defined methods
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
```
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
In the DSL you can now do:
create_table(:foos) do |t|
t.bigint :hi
end
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Inspired by @tenderlove's work in
c363fff29f060e6a2effe1e4bb2c4dd4cd805d6e, this reduces the number of
strings allocated when running callbacks for ActiveRecord instances. I
measured that using this script:
```
require 'objspace'
require 'active_record'
require 'allocation_tracer'
ActiveRecord::Base.establish_connection adapter: "sqlite3",
database: ":memory:"
ActiveRecord::Base.connection.instance_eval do
create_table(:articles) { |t| t.string :name }
end
class Article < ActiveRecord::Base; end
a = Article.create name: "foo"
a = Article.find a.id
N = 10
result = ObjectSpace::AllocationTracer.trace do
N.times { Article.find a.id }
end
result.sort.each do |k,v|
p k => v
end
puts "total: #{result.values.map(&:first).inject(:+)}"
```
When I run this against master and this branch I get this output:
```
pete@balloon:~/projects/rails/activerecord$ git checkout master
M Gemfile
Switched to branch 'master'
pete@balloon:~/projects/rails/activerecord$ bundle exec ruby benchmark_allocation_with_callback_send.rb > allocations_before
pete@balloon:~/projects/rails/activerecord$ git checkout remove-dynamic-send-on-built-in-callbacks
M Gemfile
Switched to branch 'remove-dynamic-send-on-built-in-callbacks'
pete@balloon:~/projects/rails/activerecord$ bundle exec ruby benchmark_allocation_with_callback_send.rb > allocations_after
pete@balloon:~/projects/rails/activerecord$ diff allocations_before allocations_after
39d38
<
{["/home/pete/projects/rails/activesupport/lib/active_support/callbacks.rb",
81]=>[40, 0, 0, 0, 0, 0]}
42c41
< total: 630
---
> total: 590
```
In addition to this, there are two micro-optimizations present:
* Using `block.call if block` vs `yield if block_given?` when the block was being captured already.
```
pete@balloon:~/projects$ cat benchmark_block_call_vs_yield.rb
require 'benchmark/ips'
def block_capture_with_yield &block
yield if block_given?
end
def block_capture_with_call &block
block.call if block
end
def no_block_capture
yield if block_given?
end
Benchmark.ips do |b|
b.report("block_capture_with_yield") { block_capture_with_yield }
b.report("block_capture_with_call") { block_capture_with_call }
b.report("no_block_capture") { no_block_capture }
end
pete@balloon:~/projects$ ruby benchmark_block_call_vs_yield.rb
Calculating -------------------------------------
block_capture_with_yield
124979 i/100ms
block_capture_with_call
138340 i/100ms
no_block_capture 136827 i/100ms
-------------------------------------------------
block_capture_with_yield
5703108.9 (±2.4%) i/s - 28495212 in 4.999368s
block_capture_with_call
6840730.5 (±3.6%) i/s - 34169980 in 5.002649s
no_block_capture 5821141.4 (±2.8%) i/s - 29144151 in 5.010580s
```
* Defining and calling methods instead of using send.
```
pete@balloon:~/projects$ cat benchmark_method_call_vs_send.rb
require 'benchmark/ips'
class Foo
def tacos
nil
end
end
my_foo = Foo.new
Benchmark.ips do |b|
b.report('send') { my_foo.send('tacos') }
b.report('call') { my_foo.tacos }
end
pete@balloon:~/projects$ ruby benchmark_method_call_vs_send.rb
Calculating -------------------------------------
send 97736 i/100ms
call 151142 i/100ms
-------------------------------------------------
send 2683730.3 (±2.8%) i/s - 13487568 in 5.029763s
call 8005963.9 (±2.7%) i/s - 40052630 in 5.006604s
```
The result of this is making typical ActiveRecord operations slightly faster:
https://gist.github.com/phiggins/e46e51dcc7edb45b5f98
|
| |
|
|
|
|
|
| |
Honoring an overidden `rack.test` allows testing closed connection between
multiple requests. This is useful if you're working on database resiliency, to
ensure the connection is in the expected state from one request to another on
the same worker.
|
| |
|
|
|
|
| |
it doesn't work on SQLite3 since it doesn't support truncate, but that's
OK. If you call truncate on the connection, you're now bound to that
database (same as if you use hstore or any other db specific feature).
|
| |\
| |
| |
| | |
Data corruption risk: Roll back open transactions when the running thread is killed.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Allows :limit defaults to be changed without pulling the rug out from
under old migrations that omitted :limit because it matched the default
at the time.
|
| |\ \
| | |
| | | |
Move column option handling to new_column_definition
|
| | | |
| | |
| | |
| | |
| | | |
TableDefinition#column is not called from `add_column`.
Use TableDefinition#new_column_definition for column option handling.
|
| |/ /
| |
| |
| |
| |
| |
| | |
Method .strip_heredoc is defined in
active_support/core_ext/string/strip.rb so we need to require it.
[fixes #16677]
|
| |/
|
|
|
|
|
|
|
|
| |
Using heredoc would enforce line wrapping to whatever column width we decided to
use in the code, making it difficult for the users to read on some consoles.
This does make the source code read slightly worse and a bit more error-prone,
but this seems like a fair price to pay since the primary purpose for these
messages are for the users to read and the code will not stick around for too
long.
|
| |
|
|
| |
`strip_heredoc` method is defined on active_support/core_ext/string
|
| |
|
|
|
|
|
|
| |
seamusabshere/numerify-pool-checkout-timeout-from-urls-4-1-stable
Make sure :checkout_timeout and :dead_connection_timeout are numbers
Conflicts:
activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, Active Record will rescue any errors raised within
after_rollback/after_create callbacks and print them to the
logs. Next versions of rails will not rescue those errors anymore,
and just bubble them up, as the other callbacks.
This adds a opt-in flag to enable that behaviour, of not rescuing
the errors.
Example:
# For not swallow errors in after_commit/after_rollback
config.active_record.errors_in_transactional_callbacks = true
[fixes #13460]
|
| |\
| |
| | |
Change the default `null` value for timestamps
|
| | |
| |
| |
| |
| |
| |
| | |
As per discussion, this changes the model generators to specify
`null: false` for timestamp columns. A warning is now emitted if
`timestamps` is called without a `null` option specified, so we can
safely change the behavior when no option is specified in Rails 5.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
after_commit should not run in nested transactions, however they should
run once the outermost transaction gets committed. This patch fixes the
problem copying the records from the Savepoint to its parent. So the
RealTransaction will have all records that needs to run callbacks on it.
[fixes #16425]
|
| | |
| |
| |
| |
| |
| | |
Use `commit_transaction`/`rollback_transaction` on
`within_new_transaction` method, so they make sure they `pop` the
transaction from the stack before calling the methods `commit`/`rollback`.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[Yves Senn & Matthew Draper]
The column check was embodied in the defaul index name.
If the :name option was used, the specified columns were not verified at all.
Given:
```
assert connection.index_exists?(table_name, :foo_id, :name => :index_testings_on_yo_momma)
```
That index could have been defined on any field, not necessarily on `:foo_id`.
|
| |
|
|
|
|
|
|
|
| |
Transaction class doesnt need to encapsulate the transaction state using
inheritance.
This removes all Transaction subclasses, and let the Transaction object
controls different actions based on its own state. Basically the only
actions would behave differently are `being`,`commit`,`rollback` as they
could act in a savepoint or in a real transaction.
|
| | |
|
| | |
|
| |\
| |
| | |
Transactions refactoring - 2
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
| |
This makes the implicit description of how connection pooling works a
little more explicit. It converts the examples of a model hierarchy into
actual Ruby code and demonstrates how the key structure of the
database.yml relates to the `establish_connection` method.
|
| |
|
|
|
|
|
|
|
| |
This piece of code was introduced on
67d8bb963d5d51fc644d6b1ca20164efb4cee6d7 , which was calling
`committed?` in the `transaction_state` before calling the `committed!`
method. However on 7386ffc781fca07a0c656db49fdb54678caef809, the
`committed?` check was removed and replaced by a `finalized?`, which
only checks if the state is not nil. Thus we can remove that line.
|
| | |
|
| |
|
|
| |
Also add test to assets the savepoint name
|
| |
|
|
|
|
|
| |
Add a transaction manager per connection, so it can controls the
connection responsibilities.
Delegate transaction methods to transaction_manager
|
| |
|
|
|
|
|
|
|
|
| |
The finishing variable on the transaction object was a work-around for
the savepoint name, so after a rollback/commit the savepoint could be
released with the previous name.
related:
9296e6939bcc786149a07dac334267c4035b623a
60c88e64e26682a954f7c8cd6669d409ffffcc8b
|
| |\
| |
| |
| |
| |
| | |
* Allow to specify a type for foreign key column in migrations
* unified the docs
* some cleanup in CHANGELOG
|
| |/
|
|
| |
[Andrey Novikov & Łukasz Sarnacki]
|
| |
|
|
| |
adapter, fixed from #16057 [ci skip]
|
| | |
|
| |
|
|
|
|
|
|
| |
The only case where we got a column that was not `nil`, but did not
respond to `cast_type` was when type casting the default value during
schema creation. We can look up the cast type, and add that object to
the column definition. Will allow us to consistently rely on the type
objects for type casting in all directions.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The name of the foreign key is not relevant from a users perspective.
Using random names resolves the urge to rename the foreign key when the
respective table or column is renamed.
|
| | |
|
| | |
|
| | |
|
