| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Follow up of #24844.
The key of `@owner_to_pool` was changed from `klass.name` to
`spec.name`. By this change "memory leaks in development mode"
will not happen, bacause the equality of string is not changed
by reloading of model files.
|
| |
|
|
|
|
|
|
|
| |
Some slight documentation edits and fixes. Also, run remove unnecessary
`RuntimeError`.
r? @arthurnn
|
|
|
|
| |
[skip ci]
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ConnectionHandler will not have any knowlodge of AR models now, it will
only know about the specs.
Like that we can decouple the two, and allow the same model to use more
than one connection.
Historically, folks used to create abstract AR classes on the fly in
order to have multiple connections for the same model, and override the
connection methods.
With this, now we can override the `specificiation_id` method in the
model, to return a key, that will be used to find the connection_pool
from the handler.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Example:
create_table :users do |t|
t.string :name
t.index 'lower(name) varchar_pattern_ops'
end
Fixes #19090.
Fixes #21765.
Fixes #21819.
Fixes #24359.
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
|
|
|
|
|
|
| |
There is no need to fetch all table indexes in remove_index if name is specified. If name is wrong, then StatementInvalid will be raised.
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
|
|
|
|
|
| |
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
|
| | |
|
|\ \
| | |
| | | |
Add `:nodoc:` to `insert_versions_sql` [ci skip]
|
| |/
| |
| |
| | |
Follow up to #24685. `insert_versions_sql` is not public API.
|
|/
|
|
|
| |
Follow up to #23458.
Active Record supports MySQL >= 5.0 now.
|
|
|
|
| |
Re. 6e098284e97250eaed6f30f5c7c362d87da986b0
|
|
|
|
|
|
|
|
|
| |
78 changed INSERT INTO versions to run in 1 single query.
This breaks for sqlite versions < 3.7.11, which is especially the case on Ubuntu 12.04 LTS, that has SQLite version 3.7.9 as default.
So we check for support for multi insert, before performing single query inserts, else fallback to older version of running multiple queries.
[Vipul A M & Yasuo Honda]
|
| |
|
|
|
|
| |
Follow up to #24221.
|
|\
| |
| | |
create_join_table should work with uuid
|
| | |
|
| | |
|
| |
| |
| |
| | |
comments.
|
| | |
|
|\ \
| | |
| | |
| | | |
Primary key should be `NOT NULL`
|
| |/
| |
| |
| |
| |
| |
| | |
Follow up to #18228.
In MySQL and PostgreSQL, primary key is to be `NOT NULL` implicitly.
But in SQLite it must be specified `NOT NULL` explicitly.
|
| |
| |
| |
| |
| |
| | |
* Switch to keyword args where we can without breaking compat.
* Use add_table_options! for :options, too.
* Some code polish.
|
|\ \
| | |
| | |
| | | |
Add support for specifying comments for tables, columns, and indexes in database itself
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Comments are specified in migrations, stored in database itself (in its schema),
and dumped into db/schema.rb file.
This allows to generate good documentation and explain columns and tables' purpose
to everyone from new developers to database administrators.
For PostgreSQL and MySQL only. SQLite does not support comments at the moment.
See docs for PostgreSQL: http://www.postgresql.org/docs/current/static/sql-comment.html
See docs for MySQL: http://dev.mysql.com/doc/refman/5.7/en/create-table.html
|
|\ \ \
| |/ /
|/| | |
documentation for add_references index option [ci skip]
|
| | |
| | |
| | |
| | |
| | |
| | | |
- Add link for finding the addional options for index.
- Add example for unique index as this is a common requirement.
- Add link in guide for index options.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Context #24522.
TIME column on MariaDB doesn't ignore the date part of the string when
it coerces to time.
```
root@localhost [test] > CREATE TABLE `foos` (`id` int AUTO_INCREMENT PRIMARY KEY, `start` time(0), `finish` time(4)) ENGINE=InnoDB;
Query OK, 0 rows affected (0.02 sec)
root@localhost [test] > INSERT INTO `foos` (`start`, `finish`) VALUES ('2000-01-01 12:30:00', '2000-01-01 12:30:00.999900');
Query OK, 1 row affected, 2 warnings (0.00 sec)
Note (Code 1265): Data truncated for column 'start' at row 1
Note (Code 1265): Data truncated for column 'finish' at row 1
root@localhost [test] > SELECT `foos`.* FROM `foos`;
+----+----------+---------------+
| id | start | finish |
+----+----------+---------------+
| 1 | 12:30:00 | 12:30:00.9999 |
+----+----------+---------------+
1 row in set (0.00 sec)
root@localhost [test] > SELECT `foos`.* FROM `foos` WHERE `foos`.`start` = '2000-01-01 12:30:00' LIMIT 1;
Empty set (0.00 sec)
root@localhost [test] > SELECT `foos`.* FROM `foos` WHERE `foos`.`start` = '12:30:00' LIMIT 1;
+----+----------+---------------+
| id | start | finish |
+----+----------+---------------+
| 1 | 12:30:00 | 12:30:00.9999 |
+----+----------+---------------+
1 row in set (0.00 sec)
```
|
| | |
|
|/
|
|
| |
ActiveRecord::ConnectionAdapters::SchemaStatements#add_timestamps [ci skip]
|
|\
| |
| | |
Extract `default_primary_key?` to refactor `column_spec_for_primary_key`
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
```ruby
create_table "big_numbers", force: :cascade do |t|
t.integer "bigint_column", limit: 8
end
```
After:
```ruby
create_table "big_numbers", force: :cascade do |t|
t.bigint "bigint_column"
end
```
|
|
|
| |
The comments of add_foreign_key method was displaying incorrect constraint name.
|
|
|
|
|
| |
Originally, `{insert|update|delete}_sql` is protected methods.
We can use the `{insert|update|delete}` public methods instead.
|
|\
| |
| |
| |
| | |
kamipo/exclude_name_and_type_from_prepare_column_options
Exclude `:name` and `:type` from `prepare_column_options`
|
| |
| |
| |
| | |
Actually `:name` and `:type` are not column options.
|
|\ \
| | |
| | |
| | |
| | | |
kamipo/fix_tests_failure_with_prepared_statements_false
Fix tests failure with `prepared_statements: false`
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The error occurs with `prepared_statements: false`:
```
$ ARCONN=postgresql bundle exec ruby -w -Itest test/cases/associations_test.rb
Using postgresql
Run options: --seed 27753
...E....................................
Finished in 0.713115s, 56.0919 runs/s, 91.1494 assertions/s.
1) Error:
AssociationsTest#test_force_reload_is_uncached:
NoMethodError: undefined method `preparable' for #<Arel::Visitors::PostgreSQL:0x007f8699702570>
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:68:in `block in select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:83:in `cache_sql'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:68:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/querying.rb:39:in `find_by_sql'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:699:in `exec_queries'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/association_relation.rb:32:in `exec_queries'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:580:in `load'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:260:in `records'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:256:in `to_a'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/associations/collection_association.rb:458:in `get_records'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/associations/collection_association.rb:473:in `find_target'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/associations/collection_association.rb:412:in `load_target'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/associations/collection_proxy.rb:45:in `load_target'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/associations/collection_proxy.rb:983:in `records'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/delegation.rb:39:in `each'
test/cases/associations_test.rb:116:in `block (2 levels) in test_force_reload_is_uncached'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:32:in `cache'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/query_cache.rb:9:in `cache'
test/cases/associations_test.rb:115:in `block in test_force_reload_is_uncached'
/Users/kamipo/src/github.com/rails/rails/activesupport/lib/active_support/deprecation/reporting.rb:36:in `silence'
/Users/kamipo/src/github.com/rails/rails/activesupport/lib/active_support/deprecation/instance_delegator.rb:19:in `silence'
test/cases/associations_test.rb:114:in `test_force_reload_is_uncached'
```
|
|\ \
| | |
| | | |
Publish AS::Executor and AS::Reloader APIs
|
| |/
| |
| |
| |
| |
| | |
These should allow external code to run blocks of user code to do
"work", at a similar unit size to a web request, without needing to get
intimate with ActionDipatch.
|
|\ \
| |/
|/|
| |
| | |
samphilipd/sam/properly_deallocate_prepared_statements_outside_of_transaction
Correctly deallocate prepared statements if we fail inside a transaction
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Addresses issue #12330
Overview
========
Cached postgres prepared statements become invalidated if the schema
changes in a way that it affects the returned result.
Examples:
- adding or removing a column then doing a 'SELECT *'
- removing the foo column then doing a 'SELECT bar.foo'
In normal operation this isn't a problem, we can rescue the error,
deallocate the prepared statement and re-issue the command.
However in PostgreSQL transactions, once any command fails, the
transaction becomes 'poisoned' and any subsequent commands will raise
InFailedSQLTransaction.
This includes DEALLOCATE statements, so the default deallocation
strategy instead of removing the cached prepared statement instead
raises InFailedSQLTransaction.
Why this is bad
===============
1. InFailedSQLTransaction is a fairly cryptic error and doesn't
communicate any useful information about what has actually gone wrong.
2. In the naive implementation the prepared statement never gets
deallocated - it stays alive for the length of the session taking up
memory on the postgres server.
3. It is unsafe to retry the transaction because the bad prepared
statement is still in the cache and we would see the exact same failure
repeated.
Solution
========
If we are outside a transaction we can continue to handle these failures
gracefully in the usual way.
Inside a transaction instead of issuing a DEALLOCATE command that will
certainly fail, we now raise
ActiveRecord::PreparedStatementCacheExpired.
This can be handled further up the stack, notably inside
TransactionManager#within_new_transaction. Here we can make sure to
first rollback the transaction, then safely issue DEALLOCATE statements
to invalidate the rest of the cached prepared statements.
This also allows the user (or some gem) the opportunity to catch this error and
voluntarily retry the transaction if a schema change causes the prepared
statement cache to become invalidated.
Because the outdated statement has been deallocated, we can expect the
transaction to succeed on the second try.
|
|\ \
| | |
| | | |
Fix NoMethodError preparable for Arel::Visitors::PostgreSQL
|
| | |
| | |
| | |
| | | |
is falsy
|