| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
Adding `# :nodoc:` to the parent `class` / `module` is not going
to ignore nested classes or modules.
There is a modifier `# :nodoc: all` but sadly the containing class
or module will continue to be in the docs.
/cc @sgrif
|
| |
|
|
|
|
|
| |
`ActiveRecord::ConnectionAdapters::Type::Value` =>
`ActiveRecord::Type::Value`
|
| |
|
| |
|
|\
| |
| | |
Replace `type_cast` case statement with delegation
|
| |
| |
| |
| |
| |
| |
| |
| | |
All subclasses of column were now delegating `type_cast` to their
injected type object. We can remove the overriding methods, and
generalize it on the `Column` class itself. This also enabled us to
remove several column classes completely, as they no longer had any
meaningful behavior of their own.
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The decision to wrap type registrations in a proc was made for two
reasons.
1. Some cases need to make an additional decision based on the type
(e.g. a `Decimal` with a 0 scale)
2. Aliased types are automatically updated if they type they point to is
updated later. If a user or another adapter decides to change the
object used for `decimal` columns, `numeric`, and `number` will
automatically point to the new type, without having to track what
types are aliased explicitly.
Everything else here should be pretty straightforward. PostgreSQL ranges
had to change slightly, since the `simplified_type` method is gone.
|
|
|
|
|
|
| |
Part of #15134. In order to perform typecasting polymorphically, we need
to add another argument to the constructor. The order was chosen to
match the `oid_type` on `PostgreSQLColumn`.
|
|
|
|
|
|
|
|
|
|
|
| |
* Clarify what the situation is and what to do.
* Advise loading schema using `rake db:setup` instead of migrating.
* Use a rescue in the initializer rather than extending the error
message in-place.
* Preserve the original backtrace of other errors by using `raise`
rather than raising again with `raise error`.
References 0ec45cd15d0a2f5aebc75e23d841b6c12f3ba763
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was a common pattern:
```
query = author.posts.select(:title)
connection.select_one(query)
```
However `.select` returns a ActiveRecord::AssociationRelation, which has
the bind information, so we can use that to get the right sql query.
Also fix select_rows on postgress and sqlite3 that were not using the binds
[fixes #7538]
[fixes #12017]
[related #13731]
[related #12056]
|
|
|
| |
Building on the work of #13427 this PR adds a helpful error message to the adapters: mysql, mysql2, and sqlite3
|
|
|
|
|
|
|
|
|
|
| |
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.
|