| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MySQL unicode support is not only `utf8mb4`.
Then, The index length problem is not only `utf8mb4`.
http://dev.mysql.com/doc/refman/5.6/en/charset-unicode.html
SELECT * FROM information_schema.character_sets WHERE maxlen > 3;
+--------------------+----------------------+------------------+--------+
| CHARACTER_SET_NAME | DEFAULT_COLLATE_NAME | DESCRIPTION | MAXLEN |
+--------------------+----------------------+------------------+--------+
| utf8mb4 | utf8mb4_general_ci | UTF-8 Unicode | 4 |
| utf16 | utf16_general_ci | UTF-16 Unicode | 4 |
| utf16le | utf16le_general_ci | UTF-16LE Unicode | 4 |
| utf32 | utf32_general_ci | UTF-32 Unicode | 4 |
+--------------------+----------------------+------------------+--------+
|
|
|
|
| |
we do this in other adapters, and it's a nice speed improvement
|
|\
| |
| | |
AR: translate_exception_class() no longer logs error.
|
| | |
|
|\ \
| |/
|/| |
Spike on new transaction callbacks
|
| |
| |
| |
| | |
[fixes #18903]
|
| | |
|
| |
| |
| |
| | |
boolean tinyint(1) fields
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
[Toby Ovod-Everett & Andrey Nering & Yves Senn]
Closes #17726.
Closes #10939.
This patch makes three distinct modifications:
1. no longer fall back to disabling user triggers if system triggers can't be disabled
2. warn the user when referential integrity can't be disabled
3. restore aborted transactions when referential integrity can't be disabled
The motivation behind these changes is to make the behavior of Rails
transparent and less error-prone. To require superuser privileges is not optimal
but it's what Rails currently needs. Users who absolutely rely on disabling user triggers
can patch `disable_referential_integrity`.
We should investigate `SET CONSTRAINTS` as a possible solution which does not require
superuser privileges.
/cc @matthewd
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Only `primary_key` should be extracted by d47357e in #19030, but
`new_coclumn_definition` was also extracted because #17631 is merged
previously, then #19030 is auto merged without conflicts.
This commit is for move back `new_column_definition` into
`TableDefinition`.
|
|\ \
| | |
| | | |
Extract the short-hand column methods into `ColumnMethods`
|
| | | |
|
| | | |
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Example:
create_table :foos, id: :primary_key, limit: 8 do |t|
end
# or
create_table :foos, id: false do |t|
t.column :id, limit: 8
end
|
| |
| |
| |
| | |
It is also necessary to format a time column like a datetime column.
|
| | |
|
|\ \
| | |
| | | |
Handle array option in `type_to_sql`
|
| | |
| | |
| | |
| | |
| | | |
`[]` is a part of `sql_type`, so it is always necessary to respect to
array option when `type_to_sql` is called.
|
| | | |
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
The cause by which the test suite for the mysql adapter broke in 1502cae
(reverted 89ba5bb) is because the precision was not extracted.
The rounding problem in mysql adapter has not been fixed, but `mysql_56`
helper tested only mysql2 adapter, its behavior was not apparent.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This helper no longer makes sense as a separate method. Instead I'll
just have `deserialize` call `cast` by default. This led to a random
infinite loop in the `JSON` pg type, when it called `super` from
`deserialize`. Not really a great way to fix that other than not calling
super, or continuing to have the separate method, which makes the public
API differ from what we say it is.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 1502caefd30b137fd1a0865be34c5bbf85ba64c1.
The test suite for the mysql adapter broke when this commit was used
with MySQL 5.6.
Conflicts:
activerecord/CHANGELOG.md
|
|\ \
| | |
| | |
| | | |
Add `foreign_key_exists?` method.
|
| | | |
|
| | | |
|
| | | |
|
| |/
|/|
| |
| |
| |
| | |
We do this in the adapter classes specifically, so the types aren't
registered if we don't use that adapter. Constants under the PostgreSQL
namespace for example are never loaded if we're using mysql.
|
| | |
|
|\ \
| | |
| | | |
Refactor `quote_default_expression`
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
`quote_default_expression` and `quote_default_value` are almost the same
handling for do not quote default function of `:uuid` columns. Rename
`quote_default_value` to `quote_default_expression`, and remove
duplicate code.
|
| | |
| | |
| | |
| | |
| | |
| | | |
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 latest version of the PG gem can actually convert the primitives for
us in C code, which gives a pretty substantial speed up. A few cases
were only there to add the `infinity` method, which I just put on the
range type (which is the only place it was used). Floats also needed to
parse `Infinity` and `NaN`, but it felt reasonable enough to put that on
the generic form.
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
kamipo/fix_datetime_precision_dumping_zero_for_postgresql
The datetime precision with zero should be dumped
|
| |/ /
| | |
| | |
| | |
| | | |
`precision: 0` was not dumped by f1a0fa9e19b7e4ccaea191fc6cf0613880222ee7.
However, `precision: 0` is valid value for PostgreSQL timestamps.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
MySQL rejects to remove an index which is used in a foreign key constraint:
```
ActiveRecord::StatementInvalid: Mysql2::Error: Cannot drop index 'index_copies_on_title_id': needed in a foreign key constraint: ALTER TABLE `copies` DROP `title_id`
```
Removing the constraint before removing the column (and the index) solves this problem.
|
|\ \ \
| | | |
| | | | |
Remove `cast_type` in `ColumnDefinition`
|
| |/ /
| | |
| | |
| | | |
This is no longer needed.
|
|/ /
| |
| |
| |
| | |
The keys are already validated, so it is better to use the built-in
feature to do this.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The various databases don't actually need significantly different
handling for this behavior, and they can achieve it without knowing
about the type of the object.
The old implementation was returning a string, which will cause problems
such as breaking TZ aware attributes, and making it impossible for the
adapters to supply their logic for time objects.
|
|\ \
| | |
| | | |
An array type is a part of `sql_type`
|
| | |
| | |
| | |
| | |
| | |
| | | |
`sql_type` is reused in `lookup_cast_type`. If making it a part of
`sql_type` when handled array option first, it isn't necessary to do
again.
|
| | |
| | |
| | |
| | |
| | | |
If timestamp column have the precision, it need to format according to
the precision of timestamp column.
|
|\ \ \
| | | |
| | | | |
Respect the database default charset for `schema_migrations` table.
|
| |/ /
| | |
| | |
| | |
| | |
| | | |
The charset of `version` column in `schema_migrations` table is depend
on the database default charset and collation rather than the encoding
of the connection.
|