| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
The `table_name` was added at #23677 to detect whether serial column or
not correctly.
We can do that detection before initialize column object, it makes
column object size smaller, and it probably helps column object
de-duplication.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* The database version will get cached in the schema cache file during the
schema cache dump. When the database version check happens, the version will
be pulled from the schema cache and thus avoid querying the database for
the version.
* If the schema cache file doesn't exist, we'll query the database for the
version and cache it on the schema cache object.
* To facilitate this change, all connection adapters now implement
#get_database_version and #database_version. #database_version returns the
value from the schema cache.
* To take advantage of the cached database version, the database version check
will now happen after the schema cache is set on the connection in the
connection pool.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In MySQL, the text column size is 65,535 bytes by default (1 GiB in
PostgreSQL). It is sometimes too short when people want to use a text
column, so they sometimes change the text size to mediumtext (16 MiB) or
longtext (4 GiB) by giving the `limit` option.
Unlike MySQL, PostgreSQL doesn't allow the `limit` option for a text
column (raises ERROR: type modifier is not allowed for type "text").
So `limit: 4294967295` (longtext) couldn't be used in Action Text.
I've allowed changing text and blob size without giving the `limit`
option, it prevents that migration failure on PostgreSQL.
|
|
|
|
|
|
|
|
|
|
| |
Currently `AUTO_INCREMENT` is implicitly used in the default primary key
definition. But `AUTO_INCREMENT` is not only used for single column
primary key, but also for composite primary key. In that case,
`auto_increment: true` should be dumped explicitly in the
`db/schema.rb`.
Fixes #30894.
|
|
|
|
|
|
|
| |
Currently `SchemaDumper` is only customizable for column options. But
3rd party connection adapters (oracle-enhanced etc) need to customizable
for table or index dumping also. To make it possible, I introduced
adapter specific `SchemaDumper` classes for that.
|
| |
|
|
|
|
|
| |
This is only used for the internal `column_spec` and
`column_spec_for_primary_key`.
|
| |
|
|
|
|
|
|
| |
Since MariaDB 10.2.5, `information_schema` supports Virtual Columns.
Fixes #29670.
|
|
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
|\
| |
| |
| | |
Enforce frozen string in Rubocop
|
| | |
|
|/
|
|
|
|
| |
`test_middleware_caches` is sometimes failed since #29454.
The failure is due to schema statements are affected by query caching.
Bypassing query caching for schema statements to avoid the issue.
|
|
|
|
|
|
| |
Because identifiers in SQL could include a single quote.
Related #24950, #26784.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm not sure why `Mysql2VirtualColumnTest#test_schema_dumping` passed
previously. But now the test not pass at least in MariaDB 10.1.9.
I fixed the regexp to respect `COLLATE`.
```
% ARCONN=mysql2 be ruby -w -Itest test/cases/adapters/mysql2/virtual_column_test.rb -n test_schema_dumping
Using mysql2
Run options: -n test_schema_dumping --seed 7131
F
Finished in 0.466304s, 2.1445 runs/s, 4.2890 assertions/s.
1) Failure:
Mysql2VirtualColumnTest#test_schema_dumping [test/cases/adapters/mysql2/virtual_column_test.rb:55]:
Expected /t\.virtual\s+"upper_name",\s+type: :string,\s+as: "UPPER\(`name`\)"$/i to match "# This file is auto-generated from the current state of the database. Instead\n# of editing this file, please use the migrations feature of Active Record to\n# incrementally modify your database, and then regenerate this schema definition.\n#\n# Note that this schema.rb definition is the authoritative source for your\n# database schema. If you need to create the application database on another\n# system, you should be using db:schema:load, not running all the migrations\n# from scratch. The latter is a flawed and unsustainable approach (the more migrations\n# you'll amass, the slower it'll run and the greater likelihood for issues).\n#\n# It's strongly recommended that you check this file into your version control system.\n\nActiveRecord::Schema.define(version: 0) do\n\n create_table \"virtual_columns\", force: :cascade, options: \"ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci\" do |t|\n t.string \"name\"\n t.virtual \"upper_name\", type: :string, as: \n t.virtual \"name_length\", type: :integer, as: \"LENGTH(`name`)\", stored: true\n end\n\nend\n".
1 runs, 2 assertions, 1 failures, 0 errors, 0 skips
```
```
> select @@version;
+--------------------+
| @@version |
+--------------------+
| 10.1.9-MariaDB-log |
+--------------------+
1 row in set (0.00 sec)
```
|
|
|
|
| |
Related #28399.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The native timestamp type in MySQL is different from datetime type.
Internal representation of the timestamp type is UNIX time, This means
that timestamp columns are affected by time zone.
```
> SET time_zone = '+00:00';
Query OK, 0 rows affected (0.00 sec)
> INSERT INTO time_with_zone(ts,dt) VALUES (NOW(),NOW());
Query OK, 1 row affected (0.02 sec)
> SELECT * FROM time_with_zone;
+---------------------+---------------------+
| ts | dt |
+---------------------+---------------------+
| 2016-02-07 22:11:44 | 2016-02-07 22:11:44 |
+---------------------+---------------------+
1 row in set (0.00 sec)
> SET time_zone = '-08:00';
Query OK, 0 rows affected (0.00 sec)
> SELECT * FROM time_with_zone;
+---------------------+---------------------+
| ts | dt |
+---------------------+---------------------+
| 2016-02-07 14:11:44 | 2016-02-07 22:11:44 |
+---------------------+---------------------+
1 row in set (0.00 sec)
```
|
|
|
|
|
|
|
| |
Currently schema dumper lost the unsigned option when primary key is
defined as bigint with unsigned. This commit fixes the issue.
Closes #27960
|
|
|
|
|
|
|
| |
The PR #27384 changed integer-like primary key to be autoincrement
unless an explicit default. This means that integer-like primary key is
restored as autoincrement unless dumping the default nil explicitly.
We should dump integer-like primary key with default nil correctly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MySQL generated columns: https://dev.mysql.com/doc/refman/5.7/en/create-table-generated-columns.html
MariaDB virtual columns: https://mariadb.com/kb/en/mariadb/virtual-computed-columns/
Declare virtual columns with `t.virtual name, type: …, as: "expression"`.
Pass `stored: true` to persist the generated value (false by default).
Example:
create_table :generated_columns do |t|
t.string :name
t.virtual :upper_name, type: :string, as: "UPPER(name)"
t.virtual :name_length, type: :integer, as: "LENGTH(name)", stored: true
t.index :name_length # May be indexed, too!
end
Closes #22589
|
|
|
|
|
|
| |
* Don't force PKs on tables that have explicitly opted out
* All integer-like PKs are autoincrement unless they have an explicit
default
|
| |
|
|
|
|
| |
Follow up to 99cf7558000090668b137085bfe6bcc06c4571dc.
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
Extract `default_primary_key?` to refactor `column_spec_for_primary_key`
|
| | |
|
|/
|
|
|
|
|
|
| |
working
Currently the results of `column.serial?` is not correct. For
`column.serial?` correctly working, initialize `column.table_name`
immediately.
|
| |
|
|
|
|
| |
Actually `:name` and `:type` are not column options.
|
|
|
|
|
|
|
|
|
| |
A return value of `schema_type` is used by:
1. primary key type: using as `symbol.inspect`
2. normal column type: using as `symbol.to_s`
It is better to return symbol.
|
|
|
|
| |
Such as #10404, #18206.
|
|
|
|
|
|
| |
Currently `tinyblob` is dumped to `t.binary "tiny_blob", limit: 255`.
But `t.binary ... limit: 255` is generating SQL to `varchar(255)`.
It is incorrect. This commit fixes this problem.
|
|
Current master branch includes many schema dumping improvements.
It extract these features to the appropriate files.
|