| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Method compilation provides better performance and I think the code
comes out cleaner as well.
A knock on effect is that methods that get redefined produce warnings. I
think this is a good thing. I had to deal with a bunch of warnings
coming from our tests, though.
|
| | |
|
| |
| |
| |
| |
| |
| | |
Well, not all of them, but some of them.
I don't think there's much reason for these methods to be private.
|
| | |
|
| |
| |
| |
| |
| | |
We don't need the complexity of to_sentence, and it shouldn't be a bang
method.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It's not really a good idea to have this as a global config option. We
should allow people to specify the behaviour per association.
There will now be two new values:
* :dependent => :restrict_with_exception implements the current
behaviour of :restrict. :restrict itself is deprecated in favour of
:restrict_with_exception.
* :dependent => :restrict_with_error implements the new behaviour - it
adds an error to the owner if there are dependent records present
See #4727 for the original discussion of this.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
by Active Support)
Selecting which key extensions to include in active_support/rails
made apparent the systematic usage of Object#in? in the code base.
After some discussion in
https://github.com/rails/rails/commit/5ea6b0df9a36d033f21b52049426257a4637028d
we decided to remove it and use plain Ruby, which seems enough
for this particular idiom.
In this commit the refactor has been made case by case. Sometimes
include? is the natural alternative, others a simple || is the
way you actually spell the condition in your head, others a case
statement seems more appropriate. I have chosen the one I liked
the most in each case.
|
| |
| |
| |
| |
| | |
COUNT(*) queries can be slow in PostgreSQL, #exists? avoids this by
selecting a single record.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This can be used to get a Relation from an association.
Previously we had a #scoped method, but we're deprecating that for
AR::Base, so it doesn't make sense to have it here.
This was requested by DHH, to facilitate code like this:
Project.scope.order('created_at DESC').page(current_page).tagged_with(@tag).limit(5).scoping do
@topics = @project.topics.scope
@todolists = @project.todolists.scope
@attachments = @project.attachments.scope
@documents = @project.documents.scope
end
|
| |
| |
| |
| |
| |
| |
| | |
This makes it easier to see what the documentation refers to.
It also means that we are not doing unnecessary work for delegations
that have no args / splats / block / etc.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 3803fcce26b837c0117f7d278b83c366dc4ed370.
Conflicts:
activerecord/CHANGELOG.md
It will be deprecated only in 4.0, and removed properly in 4.1.
|
| |
| |
| |
| |
| |
| | |
Move the logic for validation check to the same method, and cache
dependent option in a variable to reuse inside the dependency
configuration methods instead of relying on the options hash.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
It has been moved to active_record_deprecated_finders.
Use #to_a instead.
|
| |
| |
| |
| |
| |
| |
| | |
It doesn't serve much purpose now that ActiveRecord::Base.all returns a
Relation.
The code is moved to active_record_deprecated_finders.
|
| |
| |
| |
| | |
Closes #1190
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
This code is broken (it should say association_scope.uniq_value rather
than options[:uniq]) but the tests still pass.
I think it is designed to uniq-ify associations using finder_sql.
However, I am about to remove that anyway.
|
| | |
|
| |
| |
| |
| | |
This fixes active_record_deprecated_finders.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Improve the derivation of HABTM join table name to take account of nesting.
It now takes the table names of the two models, sorts them lexically and
then joins them, stripping any common prefix from the second table name.
Some examples:
Top level models
(Category <=> Product)
Old: categories_products
New: categories_products
Top level models with a global table_name_prefix
(Category <=> Product)
Old: site_categories_products
New: site_categories_products
Nested models in a module without a table_name_prefix method
(Admin::Category <=> Admin::Product)
Old: categories_products
New: categories_products
Nested models in a module with a table_name_prefix method
(Admin::Category <=> Admin::Product)
Old: categories_products
New: admin_categories_products
Nested models in a parent model
(Catalog::Category <=> Catalog::Product)
Old: categories_products
New: catalog_categories_products
Nested models in different parent models
(Catalog::Category <=> Content::Page)
Old: categories_pages
New: catalog_categories_content_pages
Also as part of this commit the validity checks for HABTM assocations have
been moved to ActiveRecord::Reflection One side effect of this is to move when
the exceptions are raised from the point of declaration to when the association
is built. This is consistant with other association validity checks.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Historically, update_attribute and update_attributes are similar, but
with one big difference: update_attribute does not run validations.
These two methods are really easy to confuse given their similar
names. Therefore, update_attribute is being removed in favor of
update_column.
See the thread on rails-core here:
https://groups.google.com/forum/?fromgroups#!topic/rubyonrails-core/BWPUTK7WvYA
|
|\ \
| | |
| | |
| | |
| | |
| | | |
* master-sec:
Strip [nil] from parameters hash. Thanks to Ben Murphy for reporting this!
predicate builder should not recurse for determining where columns. Thanks to Ben Murphy for reporting this
|
| | |
| | |
| | |
| | |
| | |
| | | |
Thanks to Ben Murphy for reporting this
CVE-2012-2661
|
|\ \ \ |
|
| | | | |
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I found the next issue between CollectionAssociation `delete`
and `destroy`.
class Person < ActiveRecord::Base
has_many :pets
end
person.pets.destroy(1)
# => OK, returns the destroyed object
person.pets.destroy("2")
# => OK, returns the destroyed object
person.pets.delete(1)
# => ActiveRecord::AssociationTypeMismatch
person.pets.delete("2")
# => ActiveRecord::AssociationTypeMismatch
Adding support for deleting with a fixnum or string like
`destroy` method.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|