| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Summary of the changes:
* Add thread_safe gem.
* Use thread safe cache for digestor caching.
* Replace manual synchronization with ThreadSafe::Cache in Relation::Delegation.
* Replace @attribute_method_matchers_cache Hash with ThreadSafe::Cache.
* Use TS::Cache to avoid the synchronisation overhead on listener retrieval.
* Replace synchronisation with TS::Cache usage.
* Use a preallocated array for performance/memory reasons.
* Update the controllers cache to the new AS::Dependencies::ClassCache API.
The original @controllers cache no longer makes much sense after @tenderlove's
changes in 7b6bfe84f3 and f345e2380c.
* Use TS::Cache in the connection pool to avoid locking overhead.
* Use TS::Cache in ConnectionHandler.
|
| |
| |
| |
| |
| |
| | |
This commit fixes reported issue #7630 in which counter
caches were not being updated properly when replacing
has_many_through relationships
|
|\ \
| | |
| | | |
Recognize migrations, in folders containing numbers and 'rb'
|
| | |
| | |
| | |
| | | |
Closes #8492
|
|/ /
| |
| |
| | |
paths rather than migrations. Use Migrator.open(paths) instead. Thanks @rubys!
|
|/
|
|
|
|
|
| |
The Time.time_with_datetime_fallback, Time.utc_time and Time.local_time
methods were added to handle the limitations of Ruby's native Time
implementation. Those limitations no longer apply so we are deprecating
them in 4.0 and they will be removed in 4.1.
|
|
|
|
|
|
|
| |
This can be done using the class attribute cache_timestamp_format
Conflicts:
railties/guides/source/configuring.textile
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pending work on graceful app upgrades.
Revert "Merge pull request #8439 from joshsusser/fixes"
This reverts commit ce8ac39338f86388e70356b3a470b3ea443802ae, reversing
changes made to b0e7b6f67c984d4b1502e801781ed75fad681633.
Revert "Merge pull request #8431 from joshsusser/schemadump"
This reverts commit 036d3e1c2b65c4b8cbd23de2e20ad67b9b756182, reversing
changes made to 0c692f4d121792117b6a71e5ed590a31c3b9d12e.
Revert "Merge branch 'joshsusser-master' into merge"
This reverts commit 0c692f4d121792117b6a71e5ed590a31c3b9d12e, reversing
changes made to 2e299fca715b083a60222a85e48f9d3b8dd8ce93.
Conflicts:
activerecord/CHANGELOG.md
activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb
activerecord/test/cases/schema_dumper_test.rb
|
|
|
|
|
|
|
|
|
| |
in the new 'variables:' hash in each database config section in database.yml.
The key-value pairs of this hash will be sent in a 'SET key = value, ...'
query on new database connections.
The configure_connection methods from mysql and mysql2 into are
consolidated into the abstract_mysql base class.
|
|
|
|
|
|
|
| |
* Fix example queries
* Remove doc entries of where.like/not_like.
* Remove :chain from where.not related docs. To me that's an implementation
detail and we don't expect people to use where(:chain).not.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The real win with these chain methods is where.not, that takes care of
different scenarios in a graceful way, for instance when the given value
is nil.
where("author.id != ?", author_to_ignore.id)
where.not("author.id", author_to_ignore.id)
Both where.like and where.not_like compared to the SQL versions doesn't
seem to give us that much:
Post.where("title LIKE 'ruby on%'")
Post.where.like(title: 'ruby on%'")
Post.where("title NOT LIKE 'ruby on%'")
Post.where.not_like(title: 'ruby on%'")
Thus Rails is adding where.not, but not where.like/not_like and others.
|
|
|
|
|
|
|
|
| |
This commit stems from https://github.com/rails/rails/pull/8332#issuecomment-11127957
Since the formats in which conditions can be passed to `not` differ
from the formats in which conditions can be passed to `like` and `not_like`,
then I think it's worth adding rdoc and tests to show this behavior
|
|
|
|
|
|
| |
The force flag suggests the original was probably copied
from some db/schema.rb. Thanks to Josh Susser for spotting
and reporting this.
|
|
|
|
|
|
| |
Arel::Nodes::In inherits from Arel::Nodes::Equality, so the case
statement was always using the Equality operator for both scenarios,
resulting in a not equal query instead.
|
|
|
|
|
|
|
|
| |
This commit updates the rdoc of AR#where to match the changes applied
in https://github.com/rails/rails/commit/6ba0f97 that is:
* `where(nil)` has the same effect of `where('')`: a no op
* `where` (no args) has the same effect of `where(:chain)`: to create a WhereChain
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider this scenario:
if params[:foo]
conditions = { foo: true }
end
foos = Foo.where(conditions).order(:id)
When params[:foo] is nil, this would call:
foos = Foo.where(nil).order(:id)
In this scenario, we want Foo.where(conditions) to be the same as calling
Foo.all, otherwise we'd get a "NoMethodError order for WhereChain".
Related to #8332.
|
|\
| |
| |
| |
| |
| |
| |
| | |
Relation.where with no args can be chained with not, like, and not_like
Conflicts:
activerecord/CHANGELOG.md
activerecord/lib/active_record/relation/query_methods.rb
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
examples:
Model.where.not field: nil
#=> "SELECT * FROM models WHERE field IS NOT NULL
Model.where.like name: 'Jeremy%'
#=> "SELECT * FROM models WHERE name LIKE 'Jeremy%'
this feature was originally suggested by Jeremy Kemper https://github.com/rails/rails/pull/5950#issuecomment-5591330
Closes #5950
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When applying default_scope to a class with a where clause, using
update_column(s) could generate a query that would not properly update
the record due to the where clause from the default_scope being applied
to the update query.
class User < ActiveRecord::Base
default_scope where(active: true)
end
user = User.first
user.active = false
user.save!
user.update_column(:active, true) # => false
In this situation we want to skip the default_scope clause and just
update the record based on the primary key. With this change:
user.update_column(:active, true) # => true
Fixes #8436.
|
| |
| |
| |
| |
| | |
LOCALTIMESTAMP is not support by sqlite3, and travis was giving us these
errors: https://travis-ci.org/rails/rails/jobs/3535241/#L570
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* joshsusser-master:
style cleanup
Add migration history to schema.rb dump
Add metadata to schema_migrations
Conflicts:
activerecord/CHANGELOG.md
activerecord/lib/active_record/schema.rb
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
migrated_at: timestamp when migration run
fingerprint: md5 hash of migration source
name: filename without version or extension
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Sometimes, on Mac OS X, programmers accidentally press Option+Space
rather than just Space and don’t see the difference. The problem is
that Option+Space writes a non-breaking space (0XA0) rather than a
normal space (0x20).
This commit removes all the non-breaking spaces inadvertently
introduced in the comments of the code.
|
|\ \ \
| | | |
| | | | |
Fix #8414. Performance problem with postgresql adapter primary_key function.
|
| | | | |
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
Conflicts:
guides/source/migrations.md
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This reverts commit 5ff59704f68d284381606a1b76e4ffcfd73b2cfa.
Reason: Seems dubious and adds less value.
[ci skip]
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
This reverts commit 90c887fa7d0c454b7533e208daefc342dea4d5f3.
|
| | | | |
|
| | | | |
|
| |/ / |
|
| | | |
|
|/ /
| |
| |
| | |
Closes #3313
|
|\ \
| | |
| | |
| | |
| | | |
Conflicts:
guides/source/active_record_validations.md
|
| | | |
|
| | |
| | |
| | |
| | | |
skip]
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
At present, ActiveRecord::Delegation compiles delegation methods on a
global basis. The compiled methods apply to all subsequent Relation
instances. This creates several problems:
1) After Post.all.recent has been called, User.all.respond_to?(:recent)
will be true, even if User.all.recent will actually raise an error due
to no User.recent method existing. (See #8080.)
2) Depending on the AR class, the delegation should do different things.
For example, if a Post.zip method exists, then Post.all.zip should call
it. But this will then result in User.zip being called by a subsequent
User.all.zip, even if User.zip does not exist, when in fact
User.all.zip should call User.all.to_a.zip. (There are various
variants of this problem.)
We are creating these compiled delegations in order to avoid method
missing and to avoid repeating logic on each invocation.
One way of handling these issues is to add additional checks in various
places to ensure we're doing the "right thing". However, this makes the
compiled methods signficantly slower. In which case, there's almost no
point in avoiding method_missing at all. (See #8127 for a proposed
solution which takes this approach.)
This is an alternative approach which involves creating a subclass of
ActiveRecord::Relation for each AR class represented. So, with this
patch, Post.all.class != User.all.class. This means that the delegations
are compiled for and only apply to a single AR class. A compiled method
for Post.all will not be invoked from User.all.
This solves the above issues without incurring significant performance
penalties. It's designed to be relatively seamless, however the downside
is a bit of complexity and potentially confusion for a user who thinks
that Post.all and User.all should be instances of the same class.
Benchmark
---------
require 'active_record'
require 'benchmark/ips'
class Post < ActiveRecord::Base
establish_connection adapter: 'sqlite3', database: ':memory:'
connection.create_table :posts
def self.omg
:omg
end
end
relation = Post.all
Benchmark.ips do |r|
r.report('delegation') { relation.omg }
r.report('constructing') { Post.all }
end
Before
------
Calculating -------------------------------------
delegation 4392 i/100ms
constructing 4780 i/100ms
-------------------------------------------------
delegation 144235.9 (±27.7%) i/s - 663192 in 5.038075s
constructing 182015.5 (±21.2%) i/s - 850840 in 5.005364s
After
-----
Calculating -------------------------------------
delegation 6677 i/100ms
constructing 6260 i/100ms
-------------------------------------------------
delegation 166828.2 (±34.2%) i/s - 754501 in 5.001430s
constructing 116575.5 (±18.6%) i/s - 563400 in 5.036690s
Comments
--------
Bear in mind that the standard deviations in the above are huge, so we
can't compare the numbers too directly. However, we can conclude that
Relation construction has become a little slower (as we'd expect), but
not by a huge huge amount, and we can still construct a large number of
Relations quite quickly.
|