| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
`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.
|
| | |
|
| |
|
|
|
|
| |
it doesn't work on SQLite3 since it doesn't support truncate, but that's
OK. If you call truncate on the connection, you're now bound to that
database (same as if you use hstore or any other db specific feature).
|
| |
|
|
|
|
|
|
| |
In some cases there is a difference between the two, we should always
be doing one or the other. For convenience, `type_cast` is still a
private method on type, so new types that do not need different behavior
don't need to implement two methods, but it has been moved to private so
it cannot be used accidentally.
|
| | |
|
| |
|
|
| |
See https://github.com/rails/rails/blob/master/activesupport/lib/active_support/notifications.rb#L131
|
| |
|
|
| |
It wasn't doing anything beyond clearing the statement cache.
|
| |
|
|
| |
This should make it harder to accidentally break this test.
|
| |
|
|
|
|
|
| |
We can conditional define the tests depending on the adapter or
connection.
Lets keep the skip for fail tests that need to be fixed.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I don't think this is testing anything useful, and the test code is
exceedingly brittle. It is broken since
34c7e73c1def1312e59ef1f334586ff2f668246e because the test code makes
assumptions about the implementation of PostgreSQLAdapter#active? which
are incorrect after the commit.
I could fix this test but it would be even more brittle (by stubbing the
underlying @connection.connect_poll) and it doesn't test any complex
logic. I conclude that it's not worth it.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
in the new 'variables:' hash in each database config section in database.yml.
The key-value pairs of this hash will be sent in a 'SET key = value, ...'
query on new database connections.
The configure_connection methods from mysql and mysql2 into are
consolidated into the abstract_mysql base class.
|
| |
|
|
|
| |
Didn't fail the test because adapter#query happens to
not call raw connection's #query, but don't want to count
on that and have a fragile test.
|
| |
|
|
|
|
| |
Full test requiring manual intervention was fine, but
w/ simulated disconnect, assertion was backward & still
passing. Was several kinds of wrong.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
