| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
As of MySQL 5.7.8, MySQL supports a native JSON data type.
Example:
create_table :json_data_type do |t|
t.json :settings
end
|
|
|
|
| |
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")
|
|
|
|
| |
Related with #17370.
|
|
|
|
|
| |
This line introduced by the commit fd398475 for using
`Arel::Visitors::BindVisitor`. Currently it is not used.
|
| |
|
| |
|
|\
| |
| | |
make AbstractAdapter#subquery_for private
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
MySQL does not support partial index. And, the create index algorithm in
create table can not be specified.
|
|\ \
| | |
| | |
| | | |
Correctly dump `:options` on `create_table` for MySQL
|
| | | |
|
|\ \ \
| | | |
| | | | |
PostgreSQL: `:collation` support for string and text columns
|
| | |/
| |/|
| | |
| | |
| | | |
Some databases like MySQL allow defining collation charset for specific
columns.
|
|/ / |
|
|/
|
|
|
|
| |
`change_column_null` is doc'ed only in
ActiveRecord::ConnectionAdapters::SchemaStatements, so it would make
sense to :nodoc: it elsewhere.
|
|\
| |
| |
| | |
Add charset and collation options support for MySQL string and text columns.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
columns
Example:
create_table :foos do |t|
t.string :string_utf8_bin, charset: 'utf8', collation: 'utf8_bin'
t.text :text_ascii, charset: 'ascii'
end
|
| |
| |
| |
| |
| |
| | |
It behaves in the same way that the abstract adapter.
[ci skip]
|
| | |
|
| | |
|
|\ \
| | |
| | | |
remove old unavailable link with relevant fix patch 1
|
| | | |
|
|/ / |
|
| |
| |
| |
| | |
skip]
|
|/
|
|
| |
to support MySQL 5.7.6 `optimizer_switch='derived_merge=on'`
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 |
+--------------------+----------------------+------------------+--------+
|
|
|
|
| |
boolean tinyint(1) fields
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
`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.
|
|
|
|
|
| |
If timestamp column have the precision, it need to format according to
the precision of timestamp column.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
If set to `if_exists: true`, it generates a statement like:
DROP TABLE IF EXISTS posts
This syntax is supported in the popular SQL servers, that is (at least)
SQLite, PostgreSQL, MySQL, Oracle and MS SQL Sever.
Closes #16366.
|
|
|
|
| |
`visit_ChangeColumnDefinition` is the same "CHANGE column_name " + `visit_ColumnDefinition(o)`.
|
|
|
|
|
| |
In most cases, `create_table_definition` called by table_name (the first
argument) only.
|