| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| | |
Closes #28707.
|
| |
| |
| |
| | |
Fixes GH#28706. Now rails g migration create_users and rails g model User have the same behavior for timestamps since they implement the same migration template. The expected behavior is that this create table migration will create the table with timestamps unless you pass --no-timestamps or --skip-timestamps to the generator. The expected migration should match what you get when you use the model generator. Using the migration generator, which doesn't have a class_option for timestamps would cause them to not be added to the migration file. Now the migration behavior of the migration generator, create_table only, is aligned with the migration behavior of the model generator. Also modified relevant example of ActiveRecord Migrations Guide.
|
| |
| |
| |
| | |
modifier
|
| |
| |
| |
| |
| |
| |
| | |
* Update active_record_migrations.md
* Change year to match others
[Ken Greeff + Rafael Mendonça França]
|
| | |
|
| |
| |
| |
| | |
supports it.
|
|/
|
|
|
|
|
|
|
|
| |
This reverts commit 141f50ef9ee6ce26820549e9f5b4629ddee182ce, reversing
changes made to 317efa5c3593b70e9cc9a2fcb67488a302b71731.
Reason: `add_foreign_key` and `remove_foreign_key` are implemented at
#35212.
[ci skip]
|
|\
| |
| | |
Expand intro to generator in Migrations Guide
|
| |
| |
| |
| | |
[ci skip]
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Name rails app' files relatively to its root
- `structure.sql` => `db/structure.sql`
- `schema.rb` => `db/schema.rb`
- Clarify rails commands
- `db:migrate` => `rails db:migrate`
- `db:migrate:status` => `rails db:migrate:status`
- Add `/` to the end of `db/migrate` in order to express that it is
directory and to keep consistency with `db/migrate/` above.
Follow up #33474
|
| |
| |
| |
| |
| |
| | |
Context https://github.com/rails/rails/pull/33563#discussion_r208891486.
Follow up #33563
|
|\ \
| | |
| | | |
Document best practices with old migrations
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The copy here is of course up for discussion but it feels like we need
to address the issue of old migrations in the Migration guide because
other than mentioning the canonical nature of schema.rb/structure.sql
or the actual database compared to migration files, it seems like more
guidance would help.
Here's a sample of the kinds of question people seem to often ask about
old Rails migrations:
- https://stackoverflow.com/questions/20119391/delete-old-migrations-files-in-a-rails-app
- https://www.reddit.com/r/rails/comments/4ayosd/compacting_migrations_files_or_delete_them/
- https://stackoverflow.com/questions/4248682/is-it-a-good-idea-to-purge-old-rails-migration-files
- https://stackoverflow.com/questions/707013/is-it-a-good-idea-to-collapse-old-rails-migrations
- https://stackoverflow.com/questions/1981777/rails-remove-old-models-with-migrations
- https://stackoverflow.com/questions/3343534/rebase-rails-migrations-in-a-long-running-project
The common theme seems to be: "I've got old migrations, should I keep
them around on an old project?".
My personal stance is that as long as migrations run and don't take too long do
so, you should keep them around since it allows people working on the Rails
project with you to seamlessly upgrade their local development database
without having to do a `db:drop db:schema:load` and lose all their seed data.
While writing down this suggested new section it felt like I was describing a
very cumbersome process that could be address with a rake task like:
```bash
rails db:migrate:remove VERSION=20121201123456
```
It rollback to the version just before `20121201123456`, delete the migration
file, and run `db:migrate` to get back to the latest migration.
This of course doesn't address a situation when someone would want to delete or
merge all migrations prior to a certain date, which is addressed by
[squasher](https://github.com/jalkoby/squasher).
I'm not sure this is something we want to encourage people to do. Although I
feel like with more and more production Rails apps over 5-years old, it's
definitely a concern we should address.
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | | |
albertoalmagro/albertoalmagro/prefer-rails-command-over-bin-rails
Prefer rails command over bin/rails
|
| | |
| | |
| | |
| | | |
This commit substitutes references to rails/rake task for rails command
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As discussed in #33203 rails command already looks for, and runs,
bin/rails if it is present.
We were mixing recommendations within guides and USAGE guidelines,
in some files we recommended using rails, in others bin/rails and
in some cases we even had both options mixed together.
|
|/ /
| |
| |
| |
| | |
http links will be redirected to the https version, but still better to
just directly link to the https version.
|
|/ |
|
|
|
|
|
|
|
| |
[ci skip] A regular expression was used to find a lot of missing Oxford
commas and add them. The regular expression was as follows.
", ([a-zA-Z0-9.\`:'\"]+ ){1,6}(or|and) "
|
|
|
|
| |
Introduced in #32646
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The documentation previously claimed that `db/schema.rb` was "the
authoritative source for your database schema" while simultaneously
also acknowledging that the file is generated. These two statements are
incongruous and the guides accurately call out that many database
constructs are unsupported by `schema.rb`. This change updates the
comment at the top of `schema.rb` to remove the assertion that the file
is authoritative.
The documentation also previously referred vaguely to "issues" when
re-running old migrations. This has been updated slightly to hint at the
types of problems that one can encounter with old migrations.
In sum, this change attempts to more accurately capture the pros, cons,
and shortcomings of the two schema formats in the guides and in the
comment at the top of `schema.rb`.
[Derek Prior & Sean Griffin]
Co-authored-by: Sean Griffin <sean@seantheprogrammer.com>
|
| |
|
|
|
|
|
| |
Removes default ENGINE documentation hint for MySQL and MariaDB as we
aren't taking measures to set the default ENGINE anymore.
|
| |
|
|
|
|
|
|
|
| |
Sentence had some awkward grammar and was kind of confusing, tried to make it easier
to understand what it was trying to say :)
[ci skip]
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
[ci skip]
This was pointed out on
https://github.com/rails/rails/issues/15583#issuecomment-239212831
The comment was lost in the changes made by
fcd0ac066e0959a9f4fa4459a27e041abe8eb52a and
3e1373a773085d5f19cb6a466ab2736cc1ca2713
|
| |
|
|
|
|
|
|
| |
In #23179 the migration generator was changed to no longer output `index: true` for `references` migrations. This updates the migrations guide to remove `index: true` from relevant examples.
[ci skip]
|
| |
|
|\
| |
| |
| | |
Add support for specifying comments for tables, columns, and indexes in database itself
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|\ \
| |/
|/| |
documentation for add_references index option [ci skip]
|
| |
| |
| |
| |
| |
| | |
- Add link for finding the addional options for index.
- Add example for unique index as this is a common requirement.
- Add link in guide for index options.
|
|/ |
|
|\
| |
| |
| |
| | |
Conflicts:
guides/source/association_basics.md
|
| |
| |
| |
| |
| |
| |
| | |
- We no longer add `null: false` for timestamps columns as per
rails/rails@a939506.
- Followup of
https://github.com/rails/docrails/commit/14867b1a9af813b0147bba2ae06675137d61d77b.
|
| |
| |
| |
| | |
[ci skip]
|
|/
|
|
|
|
| |
Fixed errors in rails migrations docs [ci skip]
Fixed errors in rails security docs [ci skip]
|
|
|
| |
I go through the `http://edgeguides.rubyonrails.org/` and found `rake` commands in various files that are in RAILS 5.0 implement by `bin/rails` command. I try to change all that can be directly use `bin/rails …`
|
|
|
|
| |
Still more to do. Please assist!
|
|
|
|
|
| |
Even though this means more things to change when we bump after a
release, it's more important that our examples are directly copyable.
|
|
|
|
|
|
|
|
|
|
| |
If we use a real version, at best that'll be an onerous update required
for each release; at worst, it will encourage users to write new
migrations against an older version than they're using.
The other option would be to leave these bare, without any version
specifier. But as that's just a variant spelling of "4.2", it would seem
to raise the same concerns as above.
|
|
|
|
| |
option for column
|
|
|
| |
Add 'db/'; corrects structure.rb to structure.sql
|
|
|
|
|
|
|
|
| |
I added that *structure.sql* file can be used when *db:reset* is run.
*db:reset* tasks states *db:reset* loads database from *db/schema.rb*
or *db/structure.sql* depending on the configuration (although
*db/schema.rb* is the default), hence the change.
|
|
|
|
|
|
|
|
|
|
| |
* Documentations and comments about what methods
`Migration#change` can reverse is out of date.
For example `change_column_default` is now reversible
by this [commit](https://github.com/rails/rails/pull/20018).
* Comments about `CommandRecorder` dose not match with Rails Guide.
For example `add_foreign_key` is listed only on Rails Guide.
|