| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
The only place it was accessed was in tests. Many of them have another
way that they can test their behavior, that doesn't involve reaching
into internals as far as they did. `AssociationScopeTest` is testing a
situation where the where clause would have one bind param per
predicate, so it can just ignore the predicates entirely. The where
chain test was primarly duplicating the logic tested on `WhereClause`
directly, so I instead just make sure it calls the appropriate method
which is fully tested in isolation.
|
| |
|
|
|
|
|
|
| |
Looking through the blame, this logic used to be when we actually
created the bind tuple. My guess is that `nil` couldn't be handled there
at that time. It can, now.
|
| |
|
|
|
|
|
|
|
| |
Part of the larger refactoring to remove type casting from Arel. We can
inform it that we already have the right type by wrapping the value in
an `Arel::Nodes::Quoted`. This commit can be reverted when we have
removed type casting from Arel in Rail 5.1
|
|
|
|
|
|
|
|
| |
Part of a larger refactoring to remove type casting from Arel.
/cc @mrgilman
[Sean Griffin & Melanie Gilman]
|
|
|
|
|
|
|
|
|
|
|
| |
As part of the larger refactoring to remove type casting from Arel, we
need to do the casting of values eagerly. The predicate builder is the
closest place that knows about the Active Record class, and can
therefore have the type information.
/cc @mrgilman
[Sean Griffin & Melanie Gilman]
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It seems that #where! is not designed to be used as a chained where.
See initial implementation at 8c2c60511beaad05a218e73c4918ab89fb1804f0.
So, no need to check twice.
We should not test #where!
https://github.com/rails/rails/pull/15285#discussion_r13018316
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* master: (96 commits)
clarify CHANGELOG [ci skip].
Fix Generation of proper migration when ActiveRecord::Base.pluralize_table_names = false.
update comments to reflect that options support is not available
synchronize changelogs and 4.1 release notes. [ci skip]
do not rely on method_missing hitting arel
use ARel factory methods for building AST nodes
Fix date_select option overwriting html classes
- Rename `increment_or_decrement` to an apt `set_cache_value` since it actually doesn't increment/decrement in localstore.
Check if any sqlite files are not included in the gitignore
Remove sqlite3 lines from .gitignore if the application is not using sqlite3.
Adding active_model in Rails::Info
Clean up tables after each test.
Swapped parameters of assert_equal in assert_select
Update test helper to use latest Digestor API
Digestor should just rely on the finder to know about the format and the variant -- trying to pass it back in makes a mess of things (oh, and doesnt work)
Log the full path, including variant, that the digestor is trying to find
Fix for digestor to consider variants for partials -- this still needs more testing!!
fix log_tags request object grammar
Extract with_example_table into helper method.
test for structure:dump without schema information table. refs eafec46
...
Conflicts:
activerecord/test/cases/relation/where_chain_test.rb
|
| |
| |
| |
| | |
This abstracts us from the actual construction of the nodes
|
| | |
|
|/ |
|
|
|
|
| |
argument
|
|
|
|
| |
named where condition.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The real win with these chain methods is where.not, that takes care of
different scenarios in a graceful way, for instance when the given value
is nil.
where("author.id != ?", author_to_ignore.id)
where.not("author.id", author_to_ignore.id)
Both where.like and where.not_like compared to the SQL versions doesn't
seem to give us that much:
Post.where("title LIKE 'ruby on%'")
Post.where.like(title: 'ruby on%'")
Post.where("title NOT LIKE 'ruby on%'")
Post.where.not_like(title: 'ruby on%'")
Thus Rails is adding where.not, but not where.like/not_like and others.
|
|
|
|
|
|
|
|
| |
This commit stems from https://github.com/rails/rails/pull/8332#issuecomment-11127957
Since the formats in which conditions can be passed to `not` differ
from the formats in which conditions can be passed to `like` and `not_like`,
then I think it's worth adding rdoc and tests to show this behavior
|
|
|
|
|
|
| |
Arel::Nodes::In inherits from Arel::Nodes::Equality, so the case
statement was always using the Equality operator for both scenarios,
resulting in a not equal query instead.
|
|
examples:
Model.where.not field: nil
#=> "SELECT * FROM models WHERE field IS NOT NULL
Model.where.like name: 'Jeremy%'
#=> "SELECT * FROM models WHERE name LIKE 'Jeremy%'
this feature was originally suggested by Jeremy Kemper https://github.com/rails/rails/pull/5950#issuecomment-5591330
Closes #5950
|