| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit 257fa6897d9c85da16b7c9fcb4ae3008198d320e, reversing
changes made to 94725b81f5588e4b0f43222c4f142c3135941b4b.
The build failed
https://travis-ci.org/rails/rails/builds/7883546
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an SQL improvement to ActiveRecord::Relation#blank?. Currently,
it calls `to_a` on the Relation, which loads all records in the
association, and calls `blank?` on the loaded Array. There are other
ways, however, to check the emptiness of an association that are far
more performant. `#empty?`, `#exists?` and `#any?` all attach a `LIMIT
1` to the SQL query before firing it off, which is a nice query
improvement. `#blank?` should do the same!
Bonus performance improvements will also happen for `#present?`, which
merely calls the negation of `#blank?`
Signed-off-by: David Celis <me@davidcel.is>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Inspect uses double quotes.
* Inspect puts a hash as in #<User ...>.
* Documents the return value, and makes explicit it can be an invalid record.
* Documents the method is not atomic.
* Documents a way to handle UNIQUE contraint violations in the event of a race condition.
* Removes the "Examples" header according to our guidelines.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
deprecated
Fixes activerecord-deprecated_finders build.
https://travis-ci.org/rails/activerecord-deprecated_finders/builds/5964703
|
| |
|
| |
|
|
|
|
| |
Closes #9712.
|
|
|
|
|
|
|
|
| |
The similarity of `Relation#uniq` to `Array#uniq` is confusing. Since our
Relation API is close to SQL terms I renamed `#uniq` to `#distinct`.
There is no deprecation. `#uniq` and `#uniq!` are aliases and will continue
to work. I also updated the documentation to promote the use of `#distinct`.
|
|
|
|
| |
public API.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We discussed that the auto explain feature is rarely used.
This PR removes only the automatic explain. You can still display
the explain output for any given relation using `ActiveRecord::Relation#explain`.
As a side-effect this should also fix the connection problem during
asset compilation (#9385). The auto explain initializer in the `ActiveRecord::Railtie`
forced a connection.
|
|
|
|
|
|
|
|
| |
* User class instead of Users.
* #where_values_hash does not change the value to downcase as the
example was showing.
[ci skip]
|
|
|
|
|
|
|
|
|
| |
in a default_scope.
`Model.joins(...).where(condition_on_joined_table).update_all` /
`delete_all` worked, but the same operation implemented with a
default_scope generated a SQL error because ActiveRecord ignored the
join but implemented the where condition anyways.
|
| |
|
|
|
|
|
|
|
|
| |
They was extracted from a plugin.
See https://github.com/rails/rails-observers
[Rafael Mendonça França + Steve Klabnik]
|
| |
|
| |
|
|
|
|
| |
to keep 'output' messages untouched.
|
| |
|
|
|
|
|
|
|
| |
This is similar to #first_or_create, but slightly different and a nicer
API. See the CHANGELOG/docs in the commit.
Fixes #7853
|
|
|
|
| |
https://bugs.ruby-lang.org/issues/7166
|
| |
|
|\
| |
| | |
AR::Relation#model would be a better API than AR::Relation#klass
|
| | |
|
|\ \
| | |
| | |
| | | |
Change Relation#update_all with blank argument to raise an ArgumentError
instead of trying an update with empty fields.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
This doesn't change the exernal behavior, but it moves some code around
to where I think it properly belongs.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This method explicitly loads the records and then returns `self`.
Rather than deciding between "do I want an array or a relation?",
most people are actually asking themselves "do I want to eager load
or lazy load?" Therefore, this method provides a way to explicitly
eager-load without having to switch from a `Relation` to an array.
Example:
@posts = Post.where(published: true).load
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A test was failing due to the way that Relation#inspect causes
association proxies to ignore unsaved records added to the association.
This is fixed by simply calling to_a and letting to_a figure out how to
get the records (which, in the case of associations, takes into account
new records).
I think it is acceptable to do this rather than limiting the query at
the database level:
* It's what we've done in all released Rails versions up to this point
* The goal of the limit is to not flood the console with output - this
is the problem we're targeting, rather than the actual loading of the
records from the database
* You probably want to do something with those records later anyway,
otherwise you wouldn't have built a relation for them.
|
| |
| |
| |
| | |
relation
|
| | |
|
| |
| |
| |
| | |
While it's interesting to have the results array, it can make a console or a webpage freeze if there are a lot of them.
So this limits the number of records displayed in #inspect to 10 and tells how much were effectively found.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The reason for removing the previous implementation of `#inspect` was
that it hid from you that you were dealing with a `Relation` rather than
an `Array`.
But it is still useful to be able to see the records, particularly if you're
writing something like the following in tests:
assert_equal [foo], Post.where(:bar)
If the assertion fails, you want to see what records were actually
loaded.
So this implementation makes it clear that you've got a `Relation`, but
also shows your records.
|
| | |
|