| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
`drop_table`
since 'drop table if exists' statement does not always work with some databases such as Oracle.
also Oracle drop table statement will not drop sequence objects.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
`silence_stderr`, `silence_stream`, `capture` and `quietly`.
|
| |
|
|
|
|
| |
Slightly refactoring `PostgreSQLColumn`. `array` should be readonly.
`default_function` should be initialized by `super`. `sql_type` has been
removed `[]`. Since we already choose to remove it we should not change.
|
| |
|
|
| |
PG will warn without it, but mysql2 errors out.
|
| |
|
|
|
|
|
|
|
|
|
| |
This has the same comments as 9af90ffa00ba35bdee888e3e1ab775ba0bdbe72c,
however it affects the `add_reference` method, and `t.references` in the
context of a `change_table` block.
There is a lot of duplication of code between creating and updating
tables. We should re-evaluate the structure of this code from a high
level so changes like this don't need to be made in two places. (Note to
self)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than having to do:
create_table :posts do |t|
t.references :user
end
add_foreign_key :posts, :users
You can instead do:
create_table :posts do |t|
t.references :user, foreign_key: true
end
Similar to the `index` option, you can also pass a hash. This will be
passed as the options to `add_foreign_key`. e.g.:
create_table :posts do |t|
t.references :user, foreign_key: { primary_key: :other_id }
end
is equivalent to
create_table :posts do |t|
t.references :user
end
add_foreign_key :posts, :users, primary_key: :other_id
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When running the following migration:
change_table(:table_name) { |t| t/timestamps }
The following error was produced:
wrong number of arguments (2 for 1) .... /connection_adapters/abstract/schema_statements.rb:851:in `remove_timestamps'
This is due to `arguments` containing an empty hash as its second
argument.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
If something causes the teardown block to not get run (errors,
interrupting test runs), we have to manually delete them, which is a
pain.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`add_reference` can very helpfully add a multi-column index when you use
it to add a polymorphic reference. However, the first column in the
index is the `id` column, which is less than ideal.
The [PostgreSQL docs][1] say:
> A multicolumn B-tree index can be used with query conditions that
> involve any subset of the index's columns, but the index is most
> efficient when there are constraints on the leading (leftmost)
> columns.
The [MySQL docs][2] say:
> MySQL can use multiple-column indexes for queries that test all the
> columns in the index, or queries that test just the first column, the
> first two columns, the first three columns, and so on. If you specify
> the columns in the right order in the index definition, a single
> composite index can speed up several kinds of queries on the same
> table.
In a polymorphic relationship, the type column is much more likely to be
useful as the first column in an index than the id column. That is, I'm
more likely to query on type without an id than I am to query on id
without a type.
[1]: http://www.postgresql.org/docs/9.3/static/indexes-multicolumn.html
[2]: http://dev.mysql.com/doc/refman/5.0/en/multiple-column-indexes.html
|
| |
|
|
|
|
|
|
| |
In the DSL you can now do:
create_table(:foos) do |t|
t.bigint :hi
end
|
| |
|
|
| |
to drop sequences at the same time each tables dropped for Oracle
|
| | |
|
| |
|
|
|
| |
Since 'drop table if exists' statement does not always work with
some databases such as Oracle.
|
| | |
|
| |\
| |
| | |
Change the default `null` value for timestamps
|
| | |
| |
| |
| |
| |
| |
| | |
As per discussion, this changes the model generators to specify
`null: false` for timestamp columns. A warning is now emitted if
`timestamps` is called without a `null` option specified, so we can
safely change the behavior when no option is specified in Rails 5.
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[Yves Senn & Matthew Draper]
The column check was embodied in the defaul index name.
If the :name option was used, the specified columns were not verified at all.
Given:
```
assert connection.index_exists?(table_name, :foo_id, :name => :index_testings_on_yo_momma)
```
That index could have been defined on any field, not necessarily on `:foo_id`.
|
| | |
|
| |\
| |
| |
| |
| |
| | |
* Allow to specify a type for foreign key column in migrations
* unified the docs
* some cleanup in CHANGELOG
|
| |/
|
|
| |
[Andrey Novikov & Łukasz Sarnacki]
|
| |
|
|
|
|
|
|
| |
Before this change, create_join_table would not remove the common prefix
in the join table name, unlike ActiveRecord::Reflections. A HABTM
between Music::Artist and Music::Record would use a table
music_artists_records, while create_join table would create
music_artists_music_records.
|
| |
|
|
|
| |
These tests were passing before because the precision were not using to
cast the value. Not it is being used so it would fail on sqlite3
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The name of the foreign key is not relevant from a users perspective.
Using random names resolves the urge to rename the foreign key when the
respective table or column is renamed.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This allows to create and remove foreign keys without specifying a column.
|
| | |
|
| | |
|
| |
|
|
| |
respect `table_name_prefix` and `table_name_suffix`.
|
| | |
|
| | |
|
| | |
|
| | |
|
