| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
[ci skip]
|
|
|
|
|
|
|
| |
in the case of sqlite.
Others adapters need to perform a check for validity.
Add coverage for mysql2 db type validation
|
|
|
|
|
|
|
|
| |
- Rename max to statement_limit
- Remove magic number 1000 from everywhere
- Defined StatementPool::DEFAULT_STATEMENT_LIMIT and started using it everywhere
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
|
|
|
|
|
| |
Adapters override `#supports_savepoints?` to return `true` if they
support transaction savepoints. Defaults to `false`.
|
| |
|
|
|
|
|
|
|
|
|
| |
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]
|
|
|
|
| |
`Arel::Visitors::VISITORS` was removed at https://github.com/rails/arel/pull/412.
|
|\
| |
| |
| | |
Extract `arel_visitor` and move up to the abstract adapter
|
| | |
|
|/
|
|
| |
methods to `Quoting` module
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
working
Currently the results of `column.serial?` is not correct. For
`column.serial?` correctly working, initialize `column.table_name`
immediately.
|
| |
|
| |
|
|
|
|
| |
Simply `{update|delete}_sql` aliases to `{update|delete}`.
|
|
|
|
|
| |
`sql += " WHERE 1=1"` was introduced in 69cb942.
But it is not needed. ref https://www.sqlite.org/lang_delete.html
|
|
|
|
| |
`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.
|
| |
|
|
|
|
| |
`pool` in args is unused anymore. And `config` is used in all adapters.
|
|
|
|
|
|
|
|
|
|
| |
Reported on #21509, how views is treated by `#tables` are differ
by each adapters. To fix this different behavior, after Rails 5.0
is released, deprecate `#tables`.
And `#table_exists?` would check both tables and views.
To make their behavior consistent with `#tables`, after Rails 5.0
is released, deprecate `#table_exists?`.
|
| |
|
|
|
|
|
|
| |
This issue was resolved by #21687 already. But re-add args by #18856.
`#tables` extra args was only using by `#table_exists?`. This is for
internal API. This commit will remove these extra args again.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These new methods are used from the Active Record model layer to
determine which relations are viable to back a model. These new methods
allow us to change `conn.tables` in the future to only return tables and
no views. Same for `conn.table_exists?`.
The goal is to provide the following introspection methods on the
connection:
* `tables`
* `table_exists?`
* `views`
* `view_exists?`
* `data_sources` (views + tables)
* `data_source_exists?` (views + tables)
|
|\
| |
| |
| | |
Do not dump a view as a table in sqlite3, mysql and mysql2 adapters
|
| | |
|
|\ \
| | |
| | | |
Correctly dump composite primary key
|
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
Example:
create_table :barcodes, primary_key: ["region", "code"] do |t|
t.string :region
t.integer :code
end
|
|/
|
|
|
| |
`@connection` in `StatementPool` is only used for PG adapter.
No need for abstract `StatementPool` class.
|
|
|
|
|
| |
See http://www.postgresql.org/docs/9.4/static/sql-dropindex.html
for more details.
|
|
|
|
| |
support it. Fixes #19711
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Passing `:from` and `:to` to `change_column_default` makes this command
reversible as user has defined its previous state.
So, instead of having the migration command as:
change_column_default(:posts, :state, "draft")
They can write it as:
change_column_default(:posts, :state, from: nil, to: "draft")
|
| |
|
|
|
|
|
| |
This line introduced by the commit fd398475 for using
`Arel::Visitors::BindVisitor`. Currently it is not used.
|
| |
|
|
|
|
|
|
| |
`change_column_null` is doc'ed only in
ActiveRecord::ConnectionAdapters::SchemaStatements, so it would make
sense to :nodoc: it elsewhere.
|
|
|
|
| |
we do this in other adapters, and it's a nice speed improvement
|
|
|
|
|
|
| |
As far as I can tell, the original reason that this behavior was added
has been sufficiently resolved elsewhere, as we no longer remove the
encoding of strings coming out of the database.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The same is not true of `define_attribute`, which is meant to be the low
level no-magic API that sits underneath. The differences between the two
APIs are:
- `attribute`
- Lazy (the attribute will be defined after the schema has loaded)
- Allows either a type object or a symbol
- `define_attribute`
- Runs immediately (might get trampled by schema loading)
- Requires a type object
This was the last blocker in terms of public interface requirements
originally discussed for this feature back in May. All the
implementation blockers have been cleared, so this feature is probably
ready for release (pending one more look-over by me).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The type from the column is never used, except when being passed to the
attributes API. While leaving the type on the column wasn't necessarily
a bad thing, I worry that it's existence there implies that it is
something which should be used.
During the design and implementation process of the attributes API,
there have been plenty of cases where getting the "right" type object
was hard, but I had easy access to the column objects. For any
contributor who isn't intimately familiar with the intents behind the
type casting system, grabbing the type from the column might easily seem
like the "correct" thing to do.
As such, the goal of this change is to express that the column is not
something that should be used for type casting. The only places that are
"valid" (at the time of this commit) uses of acquiring a type object
from the column are fixtures (as the YAML file is going to mirror the
database more closely than the AR object), and looking up the type
during schema detection to pass to the attributes API
Many of the failing tests were removed, as they've been made obsolete
over the last year. All of the PG column tests were testing nothing
beyond polymorphism. The Mysql2 tests were duplicating the mysql tests,
since they now share a column class.
The implementation is a little hairy, and slightly verbose, but it felt
preferable to going back to 20 constructor options for the columns. If
you are git blaming to figure out wtf I was thinking with them, and have
a better idea, go for it. Just don't use a type object for this.
|
|
|
|
|
|
|
|
| |
All columns which would map to a string primitive need this behavior.
Binary has it's own marker type, so it won't go through this conversion.
String and text, which need this, will.
Fixes #18585.
|
|
|
|
|
|
|
|
| |
`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.
|
|
|
|
| |
Fixes #18580.
|
|\
| |
| |
| | |
Clear query cache on rollback
|
| | |
|