| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| | |
Errors can be indexed with nested attributes
Close #8638
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`has_many` can now take `index_errors: true` as an
option. When this is enabled, errors for nested models will be
returned alongside an index, as opposed to just the nested model name.
This option can also be enabled (or disabled) globally through
`ActiveRecord::Base.index_nested_attribute_errors`
E.X.
```ruby
class Guitar < ActiveRecord::Base
has_many :tuning_pegs
accepts_nested_attributes_for :tuning_pegs
end
class TuningPeg < ActiveRecord::Base
belongs_to :guitar
validates_numericality_of :pitch
end
```
- Old style
- `guitar.errors["tuning_pegs.pitch"] = ["is not a number"]`
- New style (if defined globally, or set in has_many_relationship)
- `guitar.errors["tuning_pegs[1].pitch"] = ["is not a number"]`
[Michael Probber, Terence Sun]
|
| |/
|
|
|
|
| |
This class is only used internally. We should keep it out of public
documentation. This patch adds nodoc for
`ActiveRecord::Associations::Builder` and everything nested within.
|
| | |
|
| |
|
|
|
|
|
| |
To be possible to use a custom column name to save/read the polymorphic
associated type in a has_many or has_one polymorphic association, now users
can use the option :foreign_type to inform in what column the associated object
type will be saved.
|
| |
|
|
|
|
| |
When used a custom join_table name on a habtm, rails was not saving it
on Reflections. This causes a problem when rails loads fixtures, because
it uses the reflections to set database with fixtures.
|
| |
|
|
| |
This is to get activerecord-deprecated_finders work again
|
| |
|
|
| |
It is need in activerecord-deprecated_finders
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
of using +inverse_of: false+ option. Changing the documentation and
adding a CHANGELOG entry for the automatic inverse detection feature.
|
| |
|
|
|
|
| |
the results. Added tests to check to make sure that inverse associations are
automatically found when has_many, has_one, or belongs_to associations
are defined.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This change uses Module.redefine_method as defined in ActiveSupport.
Making Module.define_method public would be as clean in the code, and
would also emit warnings when redefining an association. That is pretty
messy given current tests, so I'm leaving it for someone else to decide
what approach is better.
|
| |
|
|
|
|
|
|
|
|
| |
Instead of generating association methods directly in the model
class, they are generated in an anonymous module which
is then included in the model class. There is one such module
for each association. The only subtlety is that the
generated_attributes_methods module (from ActiveModel) must
be forced to be included before association methods are created
so that attribute methods will not shadow association methods.
|
| |
|
|
|
|
| |
After a long list of discussion about the performance problem from using varargs and the reason that we can't find a great pair for it, it would be best to remove support for it for now.
It will come back if we can find a good pair for it. For now, Bon Voyage, `#among?`.
|
| |
|
|
| |
suggestion!
|
| |
|
|
| |
There're a lot of places in Rails source code which make a lot of sense to switching to Object#in? or Object#either? instead of using [].include?.
|
|
|
callbacks etc) rather than calling a whole bunch of methods with rather long names.
|
