| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Collapse where constraints to the Arel::Nodes::And node
Conflicts:
activerecord/CHANGELOG.md
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In order to remove duplication with joining arel where constraints with
`AND`, all constraints on `build_arel` are collapsed into one head node: `Arel::Nodes::And`
Closes: #11963
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Deprecate the delegation of Array bang methods in ActiveRecord::Delegation
Conflicts:
activerecord/CHANGELOG.md
activerecord/test/cases/relation_test.rb
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The primary means of returning results for Array bang methods is to modify
the array in-place. When you call these methods on a relation, that
array is created, modified, and then thrown away. Only the secondary
return value is exposed to the caller.
Removing this delegation is a straight-forward way to reduce user error
by forcing callers to first explicitly call #to_a in order to expose
the array to be acted on by the bang method.
|
|\ \ \ \
| |_|_|/
|/| | |
| | | |
| | | |
| | | |
| | | | |
Allow Relation#from to accept other relations with bind values.
Conflicts:
activerecord/CHANGELOG.md
|
| | |/
| |/| |
|
|/ /
| |
| |
| | |
The original code ignores the `false` value because `false.blank? # => true`.
|
|\ \
| |/
|/| |
Re-use order arguments pre-processing for reorder
|
| |
| |
| |
| | |
be consistent.
|
| | |
|
|\ \
| | |
| | | |
[Performance] Don't create fibers while merging bind variables
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
| |
add changelog entry for #11945
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a regression. The documentation said in its introduction
paragraph that the method returns truthy/falsy, but then below it
was said that if there were no arguments you'd get `true` or `false`.
Also when the argument is exactly `false` a singleton is documented
to be returned.
The method was not returning the singletons so it didn't conform to
those special cases.
The best solution here seems to be to just return singletons in all
cases. This solution is backwards compatible. Also, the contract
has been revised because it has no sense that the predicate varies
that way depending on the input. I bet the previous contract was just
an accident, not something mixed on purpose.
Conflicts:
activerecord/lib/active_record/relation/finder_methods.rb
activerecord/test/cases/finder_test.rb
|
|
|
|
|
|
|
|
| |
- Use symbols rather than strings where possible to avoid extra object construction
- Use destructive methods where possible to avoid extra object construction
- Use array union rather than concat followed by uniq
- Use shorthand block syntax where possible
- Use consistent multiline block styles, method names, method parenteses style, and spacing
|
|\
| |
| |
| |
| | |
Conflicts:
activerecord/CHANGELOG.md
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
order on the old ones
The previous behavior added a major backward incompatibility since it
impossible to have a upgrade path without major changes on the
application code.
We are taking the most conservative path to be consistent with the idea
of having a smoother upgrade on Rails 4.
We are reverting the behavior for what was in Rails 3.x and,
if needed, we will implement a new API to prepend the order clauses in
Rails 4.1.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the ability for rails apps or gems to have granular control
over how a domain object is converted to sql. One simple use case would
be to add support for Regexp. Another simple case would be something
like the following:
class DateRange < Struct.new(:start, :end)
def include?(date)
(start..end).cover?(date)
end
end
class DateRangePredicate
def call(attribute, range)
attribute.in(range.start..range.end)
end
end
ActiveRecord::PredicateBuilder.register_handler(DateRange,
DateRangePredicate.new)
More complex cases might include taking a currency object and converting
it from EUR to USD before performing the query.
By moving the existing handlers to this format, we were also able to
nicely refactor a rather nasty method in PredicateBuilder.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
It's not immediately clear whether you can pass in multiple relations or
not. After going through the code a bit, I saw that the arguments are
just appended to an array. Also, added nested relations example.
[ci skip]
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| | |
Blacklist->whitelist for reference scans in order!
|
| |
| |
| |
| |
| |
| | |
Stop special-casing Arel::Nodes as exempt from reference scanning in
order. Instead, only scan order values that are strings for a table
reference.
|
|/
|
|
| |
See https://github.com/rails/rails/commit/da9b5d4a8435b744fcf278fffd6d7f1e36d4a4f2#commitcomment-3630064 for discussion.
|
| |
|
| |
|
| |
|
|
|
|
| |
Perf ref: https://gist.github.com/vipulnsward/8209749201dfdd678c97
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|