| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\ \
| | |
| | | |
[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
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| | |
ActiveRecord find_in_batches should work without logger
When I set logger to nil both methods from Batches module find_in_batches or find_each should work anyway.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In 94924dc32baf78f13e289172534c2e71c9c8cade the internal default_scope
implementation has changed making it simpler to follow, meaning that the
old usage of with_default_scope has been removed.
With that, order_values was the same argument for both calls to
find_first_with_limit, so remove it and use the existent attribute
for the sake of clarity/simplification.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The previous implementation was necessary in order to support stuff
like:
class Post < ActiveRecord::Base
default_scope where(published: true)
scope :ordered, order("created_at")
end
If we didn't evaluate the default scope at the last possible moment
before sending the SQL to the database, it would become impossible to
do:
Post.unscoped.ordered
This is because the default scope would already be bound up in the
"ordered" scope, and therefore wouldn't be removed by the
"Post.unscoped" part.
In 4.0, we have deprecated all "eager" forms of scopes. So now you must
write:
class Post < ActiveRecord::Base
default_scope { where(published: true) }
scope :ordered, -> { order("created_at") }
end
This prevents the default scope getting bound up inside the "ordered"
scope, which means we can now have a simpler/better/more natural
implementation of default scoping.
A knock on effect is that some things that didn't work properly now do.
For example it was previously impossible to use #except to remove a part
of the default scope, since the default scope was evaluated after the
call to #except.
|
|\ \
| | |
| | |
| | | |
When .find_each is called without a block, return an Enumerator.
|
| |/
| |
| |
| | |
This lets us do things like call: .find_each.with_index
|
|/
|
|
|
|
|
|
| |
fixes #10669
While joining_values special treatment is given to string values.
By flattening the array it ensures that string values are detected
as strings and not arrays.
|
|\
| |
| | |
Refactored ActiveRecord `first` method to get rid of duplication.
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | | |
Conflicts:
guides/source/upgrading_ruby_on_rails.md
|
| | | |
|