| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
| |
I think that these signs are probably mistake.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Allows you to do BaseClass.new(:type => "SubClass") as well as
parent.children.build(:type => "SubClass") or parent.build_child
to initialize an STI subclass. Ensures that the class name is a
valid class and that it is in the ancestors of the super class
that the association is expecting.
|
| |
|
|
|
|
|
|
| |
They was extracted from a plugin.
See https://github.com/rails/rails-observers
[Rafael Mendonça França + Steve Klabnik]
|
| |\
| |
| |
| |
| | |
Conflicts:
actionpack/lib/action_dispatch/routing/redirection.rb
|
| | | |
|
| | |
| |
| |
| |
| | |
Thanks @toretore.
https://github.com/rails/rails/commit/9e4c41c903e8e58721f2c41776a8c60ddba7a0a9#commitcomment-2134706
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
| |
In the end I think the pain of implementing this seamlessly was not
worth the gain provided.
The intention was that it would allow plain ruby objects that might not
live in your main application to be subclassed and have persistence
mixed in. But I've decided that the benefit of doing that is not worth
the amount of complexity that the implementation introduced.
|
| |
|
|
| |
This reverts commit 83846838252397b3781eed165ca301e05db39293.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I think it's going to be too much pain to try to transition the
:active_record load hook from executing against Base to executing
against Model.
For example, after Model is included in Base, and modules included in
Model will no longer get added to the ancestors of Base.
So plugins which wish to be compatible with both Model and Base should
use the :active_record_model load hook which executes *before* Base gets
loaded.
In general, ActiveRecord::Model is an advanced feature at the moment and
probably most people will continue to inherit from ActiveRecord::Base
for the time being.
|
| |
|
|
| |
Closes #6600
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
sort the exception names alphabetically
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This is the 'top level' connection, inherited by any models that include
ActiveRecord::Model or inherit from ActiveRecord::Base.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem: We need to be able to specify configuration in a way that
can be inherited to models that include ActiveRecord::Model. So it is
no longer sufficient to put 'top level' config on ActiveRecord::Base,
but we do want configuration specified on ActiveRecord::Base and
descendants to continue to work.
So we need something like class_attribute that can be defined on a
module but that is inherited when ActiveRecord::Model is included.
The solution: added ActiveModel::Configuration module which provides a
config_attribute macro. It's a bit specific hence I am not putting this
in Active Support or making it a 'public API' at present.
|
| |
|
|
| |
before it runs
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
object. Fixes a regression from 3.0.x
|
| |
|
|
| |
fetching connection.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removing this feature causes boost in performance when using Ruby 1.9.
Ruby 1.9 started to do implicit conversions using `to_ary` and `to_str`
in some STDLIB methods (like Array#join). To do such implicit conversions,
Ruby 1.9 always dispatches the method and rescues the NoMethodError exception
in case one is raised.
Therefore, since the whiners feature defined NilClass#method_missing, such
implicit conversions for nil became much, much slower. In fact, just defining
NilClass#method_missing (even without the whiners feature) already causes a
massive slow down. Here is a snippet that shows such slow down:
require "benchmark"
Benchmark.realtime { 1_000.times { [nil,nil,nil].join } }
class NilClass
def method_missing(*args)
raise NoMethodError
end
end
Benchmark.realtime { 1_000.times { [nil,nil,nil].join } }
|
| |\
| |
| | |
Fix sequence name with abstract classes.
|
| | | |
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit vastly reduces the impact of auto
explain logging when enabled, while keeping
a negligible cost when disabled.
The first implementation was based on the idea
of subscribing to "sql.active_record" when
needed, and unsubscribing once done. This is
the idea behind AR::Relation#explain. Subscribe,
collect, unsubscribe.
But with the current implementation of notifications
unsubscribing is costly, because it wipes an internal
cache and that puts a penalty on the next event.
So we are switching to an approach where a long-running
subscriber is listening. Instead of collecting the
queries with a closure in a dedicated subscriber, now
we setup a thread local.
If the feature is disabled by setting the threshold
to nil, the subscriber will call a method that does
nothing. That's totally cheap.
|
| |/ |
|
