| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
make sql statements frozen
dup if arel is not our string
expect runtime error
dont wrap runtime error in invalid
log errors will now be treated as runtime errors
update changelog
|
|
|
|
|
|
| |
Mainly around `nil`
[ci skip]
|
|
|
|
| |
[fixes #26441]
|
|
|
|
|
|
|
| |
This reverts #23067. #23067 is for propagating `pk` value from
`sql_for_insert` to `exec_insert` (avoiding extra query for pg adapter).
Now `exec_insert` includes `sql_for_insert` since #26002 therefore this
propagating is no longer needed.
|
|\
| |
| |
| |
| | |
kamipo/sql_for_insert_should_be_called_inside_exec_insert
`sql_for_insert` should be called inside `exec_insert`
|
| |
| |
| |
| |
| | |
`exec_insert` cannot return last inserted id if `use_insert_returning?`
is true. `sql_for_insert` should be called inside `exec_insert`.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces
Fix all violations in the repository.
|
|/
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
|
| |
`insert`, `update`, `delete`, and `exec_query` have a default value
against `name` and `binds`. But `exec_insert`, `exec_update`, and
`exec_delete` not have. It is an inconvenience and inconsistent.
|
|
|
|
| |
To avoid relying on the connection adapter for type casting binds.
|
|
|
|
|
|
| |
`StatementCache` is hard-coded in `cacheable_query` and be passed
`visitor` and `collector` from connection adapter. Simply it is
enough to pass a collected value.
|
|
|
|
| |
Because `connection#to_sql` does not mutate `binds`.
|
|
|
|
|
| |
Adapters override `#supports_savepoints?` to return `true` if they
support transaction savepoints. Defaults to `false`.
|
|\
| |
| |
| |
| |
| | |
kamipo/move_select_rows_implementation_to_super_class
Move `select_rows` implementation to super class
|
| | |
|
|/
|
|
|
| |
Follow up to #23458.
Active Record supports MySQL >= 5.0 now.
|
| |
|
|
|
|
|
| |
Originally, `{insert|update|delete}_sql` is protected methods.
We can use the `{insert|update|delete}` public methods instead.
|
|
|
|
| |
is falsy
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Rails 5, we're much more restrictive about when we do or don't cache
a prepared statement. In particular, we never cache when we are sending
an IN statement or a SQL string literal
However, in the case of Adequate Record, we are *always* sending a raw
SQL string, and we *always* want to cache the result.
Fixes #23507
/cc @tgxworld
|
| |
|
| |
|
|
|
|
| |
Closes #22584.
|
|\
| |
| | |
Fix `select_values` method signature for consistency
|
| | |
|
|/
|
|
| |
Simply `{update|delete}_sql` aliases to `{update|delete}`.
|
|
|
|
| |
`connection.insert_sql` is almost the same as `connection.insert`.
|
|
|
|
|
|
| |
Originally `connection#create` had aliased to `connection#insert` in PG
adapter. But it was broken by #7447. Re-alias `create` to `insert` for
fixing it.
|
|\
| |
| | |
`join_to_delete` is same as `join_to_update`
|
| |
| |
| |
| | |
Reapply #22615.
|
|/
|
|
| |
Follow up to #22642.
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this commit, Rails makes no differentiation between whether a
query uses bind parameters, and whether or not we cache that query as a
prepared statement. This leads to the cache populating extremely fast in
some cases, with the statements never being reused.
In particular, the two problematic cases are `where(foo: [1, 2, 3])` and
`where("foo = ?", 1)`. In both cases we'll end up quoting the values
rather than using a bind param, causing a cache entry for every value
ever used in that query.
It was noted that we can probably eventually change `where("foo = ?",
1)` to use a bind param, which would resolve that case. Additionally, on
PG we can change our generated query to be `WHERE foo = ANY($1)`, and
pass an array for the bind param. I hope to accomplish both in the
future.
For SQLite and MySQL, we still end up preparing the statements anyway,
we just don't cache it. The statement will be cleaned up after it is
executed. On postgres, we skip the prepare step entirely, as an API is
provided to execute with bind params without preparing the statement.
I'm not 100% happy on the way this ended up being structured. I was
hoping to use a decorator on the visitor, rather than mixing a module
into the object, but the way Arel has it's visitor pattern set up makes
it very difficult to extend without inheritance. I'd like to remove the
duplication from the various places that are extending it, but that'll
require a larger restructuring of that initialization logic. I'm going
to take another look at the structure of it soon.
This changes the signature of one of the adapter's internals, and will
require downstream changes from third party adapters. I'm not too
worried about this, as worst case they can simply add the parameter and
always ignore it, and just keep their previous behavior.
Fixes #21992.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
skip]
Bumps from `5.6` to `5.7`
|
|
|
|
| |
Closes #21201.
|
| |
|
|
|
|
|
| |
`select_one` create `ActiveRecord::Result` instance. It is better to use
`select_rows` instead of `select_one` for performance.
|
|
|
|
| |
skip]
|
|
|
|
|
|
|
|
| |
This reverts commit a38732c8e6ab76ea0db4e1a617a1fa84b53a9750.
Since the mutation logic was reverted in
07278519bb6db5579171fea70bccdfee1306f1d4, we must bring the reader
method back as well, since the implementation relies on it.
|
| |
|
|
|
|
|
| |
The keys are already validated, so it is better to use the built-in
feature to do this.
|
|
|
|
|
| |
the transaction object shouldn't know so much about active record
objects, so let's push the conditionals in to the instance.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The goal is to remove the type object from the column, and remove
columns from the type casting process entirely. The primary motivation
for this is clarity. The connection adapter does not have sufficient
type information, since the type we want to work with might have been
overriden at the class level. By taking this object from the column,
it is easy to mistakenly think that the column object which exists on
the connection adapter is sufficient. It isn't.
A concrete example of this is `serialize`. In 4.2 and earlier, `where`
worked in a very inconsistent and confusing manner. If you passed a
single value to `where`, it would serialize it before querying, and do
the right thing. However, passing it as part of an array, hash, or range
would cause it to not work. This is because it would stop using prepared
statements, so the type casting would come from arel. Arel would have no
choice but to get the column from the connection adapter, which would
treat it as any other string column, and query for the wrong value.
There are a handful of cases where using the column object to find the
cast type is appropriate. These are cases where there is not actually a
class involved, such as the migration DSL, or fixtures. For all other
cases, the API should be designed as such that the type is provided
before we get to the connection adapter. (For an example of this, see
the work done to decorate the arel table object with a type caster, or
the introduction of `QueryAttribute` to `Relation`).
There are times that it is appropriate to use information from the
column to change behavior in the connection adapter. These cases are
when the primitive used to represent that type before it goes to the
database does not sufficiently express what needs to happen. An example
of this that affects every adapter is binary vs varchar, where the
primitive used for both is a string. In this case it is appropriate to
look at the column object to determine which quoting method to use, as
this is something schema dependent.
An example of something which would not be appropriate is to look at the
type and see that it is a datetime, and performing string parsing when
given a string instead of a date. This is the type of logic that should
live entirely on the type. The value which comes out of the type should
be a sufficiently generic primitive that the adapter can be expected to
know how to work with it.
The one place that is still using the column for type information which
should not be necessary is the connection adapter type caster which is
sometimes given to the arel table when we can't find the associated
table. This will hopefully go away in the near future.
|
|
|
|
|
|
|
|
| |
`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.
|
|
|
|
|
|
|
| |
This behavior exists only to support fixtures, so we should handle it
there. Leaving it in `#quote` can cause very subtle bugs to slip
through, by things appearing to work when they should be blowing up
loudly, such as #18385.
|
|
|
|
|
|
|
| |
I'm planning on deprecating the column argument to mirror the
deprecation in [arel].
[arel]: https://github.com/rails/arel/commit/6160bfbda1d1781c3b08a33ec4955f170e95be11
|
| |
|
| |
|