| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`prefetch_primary_key?` and `next_sequence_value` methods live in the
connection level at the moment, that make sense when you are generating
the sequence from the database, in the same connection. Which is the use
case today at the Oracle and Postgres adapters.
However if you have an service that generates IDs, that has nothing to
do with the database connection, and should not be fetched from there.
Another use case, is if you want to use another connection to fetch IDs,
that would not be possible with the current implementation, however when
we move those methods to the model level, you can use a new connection
there.
Also this makes easier for gems to add behavior on those methods.
|
|
|
|
|
|
| |
Clarifying this separation and enforcing relation immutability is the
culmination of the previous efforts to remove the mutator method
delegations.
|
| |
|
|
|
|
|
| |
This still isn't as separated as I'd like, but it at least moves most of
the burden of alias mapping in one place.
|
|
|
|
| |
Arel handles substitution for bind parameters by now.
|
| |
|
|
|
|
| |
Reapply #22615.
|
|
|
|
|
|
|
|
|
|
| |
kamipo/join_to_delete_is_same_as_join_to_update"
This reverts commit 4d06ea9a829de8f6f5a345589828e182eacab6a3, reversing
changes made to e9d15072a94e2ae4dec5b7a121c84a5db38547b8.
Reason: This will break oracle-enhanced, see
https://github.com/rsim/oracle-enhanced/blob/3c42131db82b64ac41645db3affc6e4650289df6/lib/active_record/connection_adapters/oracle_enhanced_adapter.rb#L1254
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit 6d5b1fdf55611de2a1071c37544933bb588ae88e.
`eager_load` and `references` can include hashes, which won't match up
with `references`
A test case has been added to demonstrate the problem
|
|
|
|
|
|
|
|
|
|
|
| |
This was changed in 421c81b, as `exists?` blows up if you are eager
loading a polymorphic association, as it'll try to construct a join to
that table. The previous change decided to execute a `count` instead,
which wouldn't join.
Of course, the only time we actually need to perform a join on the eager
loaded values (which would perform a left outer join) is if they're
being referenced in the where clause. This doesn't affect inner joins.
|
| |
|
| |
|
|\
| |
| |
| | |
added ActiveRecord::Relation#outer_joins
|
| |
| |
| |
| |
| |
| | |
Example:
User.left_outer_joins(:posts)
=> SELECT "users".* FROM "users" LEFT OUTER JOIN "posts" ON "posts"."user_id" = "users"."id"
|
| |
| |
| |
| |
| |
| |
| |
| | |
When passing an instance of `ActiveRecord::Base` to `#update`, it would
internally call `#find`, resulting in a misleading deprecation warning.
This change gives this deprecated use of `#update` its own, meaningful
warning.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The focus of this change is to make the API more accessible.
References to method and classes should be linked to make it easy to
navigate around.
This patch makes exzessiv use of `rdoc-ref:` to provide more readable
docs. This makes it possible to document `ActiveRecord::Base#save` even
though the method is within a separate module
`ActiveRecord::Persistence`. The goal here is to bring the API closer to
the actual code that you would write.
This commit only deals with Active Record. The other gems will be
updated accordingly but in different commits. The pass through Active
Record is not completely finished yet. A follow up commit will change
the spots I haven't yet had the time to update.
/cc @fxn
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* before
```
people = Person.where(group: 'expert')
people.update(group: 'masters')
Note: Updating a large number of records will run a
UPDATE query for each record, which may cause a performance
issue. So if it is not needed to run callbacks for each update, it is
preferred to use <tt>update_all</tt> for updating all records using
a single query.
```
* after
```
people = Person.where(group: 'expert')
people.update(group: 'masters')
```
Note: Updating a large number of records will run an
UPDATE query for each record, which may cause a performance
issue. So if it is not needed to run callbacks for each update, it is
preferred to use <tt>update_all</tt> for updating all records using
a single query.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`in_batches` yields Relation objects if a block is given, otherwise it
returns an instance of `BatchEnumerator`. The existing `find_each` and
`find_in_batches` methods work with batches of records. The new API
allows working with relation batches as well.
Examples:
Person.in_batches.each_record(&:party_all_night!)
Person.in_batches.update_all(awesome: true)
Person.in_batches.delete_all
Person.in_batches.map do |relation|
relation.delete_all
sleep 10 # Throttles the delete queries
end
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
After discussing, we've decided it makes more sense to include it. We're
already forwarding every conflicting method to `to_a`, and there's no
conflation of concerns. `Enumerable` has no mutating methods, and it
just allows us to simplify the code. No existing methods will have a
change in behavior. Un-overridden Enumerable methods will simply
delegate to `each`.
[Sean Griffin & bogdan]
|
|/
|
|
|
|
|
|
|
| |
See #9683 for the reasons we switched to `distinct`.
Here is the discussion that triggered the actual deprecation #20198.
`uniq`, `uniq!` and `uniq_value` are still around.
They will be removed in the next minor release after Rails 5.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code in the comment fails on concurrent inserts if done inside a transaction.
The fix is to force a savepoint to run so that if the database raises an unique violation exception. Otherwise, you'll get errors like:
```
(0.3ms) BEGIN
Cart Load (0.5ms) SELECT "carts".* FROM "carts" WHERE "carts"."uuid" = '12345' LIMIT 1
# Another process inserts a cart with uuid of '12345' right now
SQL (4371.7ms) INSERT INTO "carts" ("created_at", "updated_at", "uuid") VALUES ('2015-03-21 01:05:07.833231', '2015-03-21 01:05:07.833231', '12345') RETURNING "id" [["created_at", Sat, 21 Mar 2015 01:05:07 PDT -07:00], ["updated_at", Sat, 21 Mar 2015 01:05:07 PDT -07:00], ["uuid", "12345"]]
PG::UniqueViolation: ERROR: duplicate key value violates unique constraint "carts_uuid_idx1"
DETAIL: Key (uuid)=(12345) already exists.
: INSERT INTO "carts" ("created_at", "updated_at", "uuid") VALUES ('2015-03-21 01:05:07.833231', '2015-03-21 01:05:07.833231', '12345') RETURNING "id"
# Retrying the find
Cart Load (0.8ms) SELECT "carts".* FROM "carts" WHERE "carts"."uuid" = '12345' LIMIT 1
PG::InFailedSqlTransaction: ERROR: current transaction is aborted, commands ignored until end of transaction block
: SELECT "carts".* FROM "carts" WHERE "carts"."uuid" = '12345' LIMIT 1
(0.1ms) ROLLBACK
ActiveRecord::StatementInvalid: PG::InFailedSqlTransaction: ERROR: current transaction is aborted, commands ignored until end of transaction block
: SELECT "carts".* FROM "carts" WHERE "carts"."uuid" = '12345' LIMIT 1
```
|
|
|
|
|
|
|
|
| |
Use SQL COUNT and LIMIT 1 queries for none? and one? methods if no block or limit is given,
instead of loading the entire collection to memory. The any? and many? methods already
follow this behavior.
[Eugene Gilburg & Rafael Mendonça França]
|
|
|
|
|
|
|
|
| |
`bound_attributes` is now used universally across the board, removing
the need for the conversion layer. These changes are mostly mechanical,
with the exception of the log subscriber. Additional, we had to
implement `hash` on the attribute objects, so they could be used as a
key for query caching.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bind values can come from four places. `having`, `where`, `joins`,
and `from` when selecting from a subquery that contains binds. These
need to be kept in a specific order, since the clauses will always
appear in that order. Up until recently, they were not.
Additionally, `joins` actually did keep its bind values in a separate
location (presumably because it's the only case that people noticed was
broken). However, this meant that anything accessing just `bind_values`
was broken (which most places were). This is no longer possible, there
is only a single way to access the bind values, and it includes joins in
the proper location. The setter was removed yesterday, so breaking `+=`
cases is not possible.
I'm still not happy that `joins` is putting it's bind values on the
Arel AST, and I'm planning on refactoring it further, but this removes a
ton of bug cases.
|
|
|
|
|
|
|
| |
Contrary to my previous commit message, it wasn't overkill, and led to
much cleaner code.
[Sean Griffin & anthonynavarre]
|
|
|
|
|
|
|
|
|
|
| |
The last place that was assigning it was when `from` is called with a
relation to use as a subquery. The implementation was actually
completely broken, and would break if you called `from` more than once,
or if you called it on a relation, which also had its own join clause,
as the bind values would get completely scrambled. The simplest solution
was to just move it into its own array, since creating a `FromClause`
class for this would be overkill.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixed an issue where `having` can only be called after the last
call to `where`, because it messes with the same `bind_values` array.
With this change, the two can be called as many times as needed, in any
order, and the final query will be correct. However, once something
assigns `bind_values`, that stops. This is because we have to move all
of the bind values from the having clause over to the where clause since
we can't differentiate the two, and assignment was likely in the form
of:
`relation.bind_values += other.bind_values`
This will go away once we remove all places that are assigning
`bind_values`, which is next on the list.
While this fixes a bug that was present in at least 4.2 (more likely
present going back as far as 3.0, becoming more likely in 4.1 and later
as we switched to prepared statements in more cases), I don't think this
can be easily backported. The internal changes to `Relation` are
non-trivial, anything that involves modifying the `bind_values` array
would need to change, and I'm not confident that we have sufficient test
coverage of all of those locations (when `having` was called with a hash
that could generate bind values).
[Sean Griffin & anthonynavarre]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The way that bind values are currently stored on Relation is a mess.
They can come from `having`, `where`, or `join`. I'm almost certain that
`having` is actually broken, and calling `where` followed by `having`
followed by `where` will completely scramble the binds.
Joins don't actually add the bind parameters to the relation itself, but
instead add it onto an accessor on the arel AST which is undocumented,
and unused in Arel itself. This means that the bind values must always
be accessed as `relation.arel.bind_values + relation.bind_values`.
Anything that doesn't is likely broken (and tons of bugs have come up
for exactly that reason)
The result is that everything dealing with `Relation` instances has to
know far too much about the internals. The binds are split, combined,
and re-stored in non-obvious ways that makes it difficult to change
anything about the internal representation of `bind_values`, and is
extremely prone to bugs.
So the goal is to move a lot of logic off of `Relation`, and into
separate objects. This is not the same as what is currently done with
`JoinDependency`, as `Relation` knows far too much about its internals,
and vice versa. Instead these objects need to be black boxes that can
have their implementations swapped easily.
The end result will be two classes, `WhereClause` and `JoinClause`
(`having` will just re-use `WhereClause`), and there will be a single
method to access the bind values of a `Relation` which will be
implemented as
```
join_clause.binds + where_clause.binds + having_clause.binds
```
This is the first step towards that refactoring, with the internal
representation of where changed, and an intermediate representation of
`where_values` and `bind_values` to let the refactoring take small
steps. These will be removed shortly.
|
|
|
|
|
|
|
| |
In order to better facilitate refactoring, most places that mutated
`bind_values` have already been removed. One last spot snuck through.
Since we're no longer mutating the array, it also does not need to be
duped in `initialize_copy`.
|
|
|
|
|
|
|
| |
I'm planning on deprecating the column argument to mirror the
deprecation in [arel].
[arel]: https://github.com/rails/arel/commit/6160bfbda1d1781c3b08a33ec4955f170e95be11
|
|\
| |
| |
| |
| |
| |
| | |
Changed ActiveRecord::Relation#update behavior so that it will work on Relation objects without giving id
Conflicts:
activerecord/CHANGELOG.md
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
callbacks and validations
- Right now, there is no method to update multiple records with
validations and callbacks.
- Changed the behavior of existing `update` method so that when `id`
attribute is not given and the method is called on an `Relation`
object, it will execute update for every record of the `Relation` and
will run validations and callbacks for every record.
- Added test case for validating that the callbacks run when `update` is
called on a `Relation`.
- Changed test_create_columns_not_equal_attributes test from
persistence_test to include author_name column on topics table as it
it used in before_update callback.
- This change introduces performance issues when a large number of
records are to be updated because it runs UPDATE query for every
record of the result. The `update_all` method can be used in that case
if callbacks are not required because it will only run single UPDATE
for all the records.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This error only happens when the foreign key is missing.
Before this fix the following exception was being raised:
NoMethodError: undefined method `val' for #<Arel::Nodes::BindParam:0x007fc64d19c218>
Now the message is:
ActiveRecord::UnknownAttributeError: unknown attribute 'foreign_key' for Model.
|
|/
|
|
|
|
|
| |
Construction of relations can be a hotspot, we don't want to create one
of these in the constructor. This also allows us to do more expensive
things in the predicate builder's constructor, since it's created once
per AR::Base subclass
|
|
|
|
| |
In order to maintain thread safety and prevent race condition from memoization.
|
| |
|
|
|
|
|
| |
`where_sql` now requires that we pass it an engine. None of the manager
classes take an engine in their constructor.
|
| |
|
|
|
| |
It now contains a carefully formulated reference to the "current relation" which might help clarify that the receiving will generate its own scope, escaping the need for explicitly referencing `default_scope` which is, after all, just another way of specifying a scope and nothing special.
|
|
|
|
|
| |
This was not explicitly stated before and I needed to try it out to be
certain. A little explicit statement in the API docs might help here.
|
| |
|
|
|
|
| |
Oh hey, we got to remove some code because of that!
|
|
|
|
|
|
| |
Arel handles this for us automatically. Updated tests, as BindParam is
no longer a subclass of SqlLiteral. We should remove the second argument
to substitute_at entirely, as it's no longer used
|
|
|
|
|
|
| |
We need to re-order the bind parameters since the AST returned by the
relation will have the where statement as the first bp, which breaks on
PG.
|