diff options
| author | Derek Prior <derekprior@gmail.com> | 2018-04-19 15:41:01 -0400 |
|---|---|---|
| committer | Derek Prior <derekprior@gmail.com> | 2018-04-24 11:18:11 -0400 |
| commit | 84718df86097442f85999d6f2e6f6b8b59724c3f (patch) | |
| tree | 0b5967db5a3e0e333e5bffd42f9f9f150071ab11 /activerecord/lib | |
| parent | fb9ed7b0dff7dcf8a00e42cd45ec645211c04afc (diff) | |
| download | rails-84718df86097442f85999d6f2e6f6b8b59724c3f.tar.gz rails-84718df86097442f85999d6f2e6f6b8b59724c3f.tar.bz2 rails-84718df86097442f85999d6f2e6f6b8b59724c3f.zip | |
Update schema.rb documentation [CI SKIP]
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>
Diffstat (limited to 'activerecord/lib')
| -rw-r--r-- | activerecord/lib/active_record/schema_dumper.rb | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/activerecord/lib/active_record/schema_dumper.rb b/activerecord/lib/active_record/schema_dumper.rb index 9974c28445..d475e77444 100644 --- a/activerecord/lib/active_record/schema_dumper.rb +++ b/activerecord/lib/active_record/schema_dumper.rb @@ -71,11 +71,11 @@ module ActiveRecord # of editing this file, please use the migrations feature of Active Record to # incrementally modify your database, and then regenerate this schema definition. # -# Note that this schema.rb definition is the authoritative source for your -# database schema. If you need to create the application database on another -# system, you should be using db:schema:load, not running all the migrations -# from scratch. The latter is a flawed and unsustainable approach (the more migrations -# you'll amass, the slower it'll run and the greater likelihood for issues). +# This file is the source Rails uses to define your schema when running `rails +# db:schema:load`. When creating a new database, `rails db:schema:load` tends to +# be faster and is potentially less error prone than running all of your +# migrations from scratch. Old migrations may fail to apply correctly if those +# migrations use external dependencies or application code. # # It's strongly recommended that you check this file into your version control system. |