| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
This will fix the [broken
test](https://github.com/rails/rails/commit/4a2650836680f51490e999c3c8441a2f9adff96e)
`test_with_limiting_with_custom_select`.
The query's result was built in a hash with column name as key, if the
result have a duplicated column name the last value was
overriding the first one.
|
|\
| |
| |
| |
| | |
dougbarth/dont_swallow_exceptions_during_transactional_statements_in_mysql
Don't swallow exceptions in transctional statements
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The MySQL connection adapater swallows all StandardError exceptions,
which includes Mysql::Error and Mysql2::Error. The comment in the
exception clause claims errors thrown here indicate that transactions
aren't supported by the server but that isn't necessarily true. It's
possible the MySQL server has gone away and swallowing a failed commit
may let the application return a successful response when the data has
not been saved. Also, replication libraries like Galera require that the
application handle exceptions thrown at BEGIN/COMMIT.
I'm unable to determine what version of MySQL threw an exception for
transactional statements. I tried as far back as 3.23.49 with InnoDB
disabled but BEGIN & COMMIT statements do not throw an error. If there's
a real case for this logic to continue, we could instead push this
behavior into a configuration setting.
The exception swallowing has been there since the beginning:
db045dbbf60b53dbe013ef25554fd013baf88134
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The log output used to be confusing in situation where type casting has
"unexpected" effects. For example when finding records with a `String`.
BEFORE:
irb(main):002:0> Event.find("im-no-integer")
D, [2013-11-09T11:10:28.998857 #1706] DEBUG -- : Event Load (4.5ms) SELECT "events".* FROM "events" WHERE "events"."id" = $1 LIMIT 1 [["id", "im-no-integer"]]
AFTER:
irb(main):002:0> Event.find("im-no-integer")
D, [2013-11-09T11:10:28.998857 #1706] DEBUG -- : Event Load (4.5ms) SELECT "events".* FROM "events" WHERE "events"."id" = $1 LIMIT 1 [["id", 0]]
|
| |
|
|
|
|
| |
This is not valid anymore after 08477a651648ba4417ded128aa37b9ae0dcbc9ce
|
|
|
|
|
|
|
|
|
| |
When the adapter is with prepared statement disabled and the binds array
is not empty the connection adapter will try to set the binds values and
will fail. Now we are checking if the adapter has the prepared statement
disabled.
Fixes #12023
|
| |
|
| |
|
|
|
| |
`result_metadata` returns a new object each time it is called, so calling `result_metadata.free` is essentially a noop. Instead call `free` directly on the metadata when we're done with it.
|
|
|
|
|
| |
This reverts commit cb1d07e43926bcec95cb8b4a663ca9889173395a, reversing
changes made to 754a373e301d2df0b12a11083405252722bc8366.
|
|
|
|
|
| |
Using the mysql2 adapter, boolean values were sometimes being incorrectly cast
to 't' or 'f'. This changes the cast to match the mysql adapter behavior, ie 1 and 0.
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb
activerecord/test/cases/adapter_test.rb
guides/source/testing.md
[ci skip]
|
| | |
|
|/ |
|
|
|
|
|
|
| |
We should only type cast when we need to use.
Related to 4b005fb371c2e7af80df7da63be94509b1db038c
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
In non-strict mode it is '', but if someone is in strict mode then we
should honour the strict semantics.
Also, this removes the need for a completely horrible hack in dirty.rb.
Closes #7780
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Conflicts:
activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prepared statements (prepare/execute/close) were being used unnecessarily
when no bind variables were present, and disabling prepared statement using
prepared_statements:false was principally broken. While bind variables were
correctly substituted with prepared_statements:false, the prepared statement
interface was still used, costing an extra two round trips per query.
In addition to making this behavioral change, I also cleaned up the internals
of exec_stmt and exec_without_stmt so that they behave the same (calling log
and constructing the ActiveRecord::Result in the same way).
Moving the check for binds.empty? to exec_query also will mean that several
code paths explicitly calling exec_without_stmt could be cleaned up to once
again call exec_query instead. I have also left the check for binds.empty? in
exec_stmt, since it is not a private method and could be called directly with
an empty binds array. For the sake of clarity in this patch, I have not made
those changes.
= The previous behavior =
When issuing a Foo.find(1) with prepared_statements:true, the bind variable
is present in the prepared query, and execute shows a value passed:
Connect root@localhost on rails_test
Query SET SQL_AUTO_IS_NULL=0
Statistics
Query SHOW FULL FIELDS FROM `foos`
Query SHOW TABLES LIKE 'foos'
Query SHOW CREATE TABLE `foos`
Prepare SELECT `foos`.* FROM `foos` WHERE `foos`.`id` = ? LIMIT 1
Execute SELECT `foos`.* FROM `foos` WHERE `foos`.`id` = 1 LIMIT 1
Close stmt
Quit
When issuing a Foo.find(1) with prepared_statements:false, the bind variable
has already been removed and substituted with the value, but the prepared
statement interface is used anyway:
Connect root@localhost on rails_test
Query SET SQL_AUTO_IS_NULL=0
Statistics
Query SHOW FULL FIELDS FROM `foos`
Query SHOW TABLES LIKE 'foos'
Query SHOW CREATE TABLE `foos`
Prepare SELECT `foos`.* FROM `foos` WHERE `foos`.`id` = 1 LIMIT 1
Execute SELECT `foos`.* FROM `foos` WHERE `foos`.`id` = 1 LIMIT 1
Close stmt
Quit
= With this patch applied =
When issuing a Foo.find(1) with prepared_statements:true, the bind variable
is present in the prepared query, and execute shows a value passed:
Connect root@localhost on rails_test
Query SET SQL_AUTO_IS_NULL=0
Statistics
Query SHOW FULL FIELDS FROM `foos`
Query SHOW TABLES LIKE 'foos'
Query SHOW CREATE TABLE `foos`
Prepare SELECT `foos`.* FROM `foos` WHERE `foos`.`id` = ? LIMIT 1
Execute SELECT `foos`.* FROM `foos` WHERE `foos`.`id` = 1 LIMIT 1
Close stmt
Quit
When issuing a Foo.find(1) with prepared_statements:false, the bind variable
has been removed and substituted with the value, and the query interface is
used instead of the prepared statement interface:
Connect root@localhost on rails_test
Query SET SQL_AUTO_IS_NULL=0
Statistics
Query SHOW FULL FIELDS FROM `foos`
Query SHOW TABLES LIKE 'foos'
Query SHOW CREATE TABLE `foos`
Query SELECT `foos`.* FROM `foos` WHERE `foos`.`id` = 1 LIMIT 1
Quit
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This is the 'top level' connection, inherited by any models that include
ActiveRecord::Model or inherit from ActiveRecord::Base.
|
| |
|
| |
|
|
|
|
| |
case sensitive collation.
|
| |
|
|
|
|
|
|
| |
Database adapters use a statement pool for limiting the number of open
prepared statments on the database. The limit defaults to 1000, but can
be adjusted in your database config by changing 'statement_limit'.
|
| |
|
|
|
|
| |
supported for mysql2 as well now.
|
| |
|
|
|
|
| |
MysqlAdapter and Mysql2Adapter.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|