| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
Restore the behaviour of the compatibility layer for integer-like PKs
* kamipo/fix_mysql_pk_dumping_correctly:
Restore custom primary key tests lost at #26266
Restore the behaviour of the compatibility layer for integer-like PKs
Correctly dump integer-like primary key with default nil
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
|
|
| |
`ColumnDumper#migration_keys` was extracted to customize keys for
standardized column arguments widths. But the feature was removed in
df84e98. The internal method is no longer used for that.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
|
|
|
| |
`migration_keys` includes `name` but `name` is not a column option.
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
| |
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.
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\
| |
| | |
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
```
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
Example:
create_table :posts do |t|
t.datetime :published_at, default: -> { 'NOW()' }
end
|
|\
| |
| |
| |
| |
| | |
byroot/do-not-include-column-limit-if-it-is-default
Do not include column limit in schema.rb if it matches the default
|
| |
| |
| |
| |
| |
| |
| |
| | |
When working on engines that supports multiple databases, it's
very annoying to have a different schema.rb output based on which
database you use. MySQL being the primary offender.
This patch should reduce the disparities a bit.
|
| |
| |
| |
| |
| | |
Current master branch includes many schema dumping improvements.
It extract these features to the appropriate files.
|
|/ |
|
| |
|
|
|
|
|
| |
Some databases like MySQL allow defining collation charset for specific
columns.
|
| |
|
| |
|
|
|
|
|
| |
`precision: 0` was not dumped by f1a0fa9e19b7e4ccaea191fc6cf0613880222ee7.
However, `precision: 0` is valid value for PostgreSQL timestamps.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Remaining are `limit`, `precision`, `scale`, and `type` (the symbol
version). These will remain on the column, since they mirror the options
to the `column` method in the schema definition DSL
|
|
|
|
| |
If it is not a default primary key, correctly dump the type and options.
|
| |
|
| |
|
|
|
|
|
|
| |
Allows :limit defaults to be changed without pulling the rug out from
under old migrations that omitted :limit because it matched the default
at the time.
|
|
|
|
|
|
|
| |
If we want to have type decorators mess with the attribute, but not the
column, we need to stop type casting on the column. Where possible, we
changed the tests to test the value of `column_defaults`, which is
public API. `Column#default` is not.
|
|
|
|
| |
We're not longer using `ipaddr` in schema dumper
|
|
|
|
|
|
|
| |
This removes the case statement in `SchemaDumper` and gives every `Type`
the possibility to control the SchemaDumper default value output.
/cc @sgrif
|
| |
|
|
|
|
|
|
|
| |
ActiveRecord::ConnectionAdapters::Column
See
https://github.com/rails/rails/blob/28b8ca766e3e7c6c43d3ae900c99f8377153c62/activerecord/lib/active_record/connection_adapters/column.rb#L16
|
| |
|
| |
|
| |
|
|
Having column related schema dumper code in the AbstractAdapter. The
code remains the same, but by placing it in the AbstractAdapter, we can
then overwrite it with Adapter specific methods that will help with
Adapter specific data types.
The goal of moving this code here is to create a new migration key for
PostgreSQL's array type. Since any datatype can be an array, the goal is
to have ':array => true' as a migration option, turning the datatype
into an array. I've implemented this in postgres_ext, the syntax is
shown here: https://github.com/dockyard/postgres_ext#arrays
Adds array migration support
Adds array_test.rb outlining the test cases for array data type
Adds pg_array_parser to Gemfile for testing
Adds pg_array_parser to postgresql_adapter (unused in this commit)
Adds schema dump support for arrays
Adds postgres array type casting support
Updates changelog, adds note for inet and cidr support, which I forgot to add before
Removing debugger, Adds pg_array_parser to JRuby platform
Removes pg_array_parser requirement, creates ArrayParser module used by
PostgreSQLAdapter
|