11

My database uses PostgreSQL. I develop on Mac and this line is needed:

  # db/schema.rb on Mac environment
  enable_extension "plpgsql"

However, the extension is not required on Linux.

In this case, should we just ignore schema.rb and generate that through db:migrate for both dev and production environments?

Chris Travers
  • 25,424
  • 6
  • 65
  • 182
Clucking Turtle
  • 922
  • 1
  • 11
  • 24
  • It doesn't seem to hurt production. – Clucking Turtle Sep 18 '13 at 06:11
  • However, Git complains whenever pulling when I forget to `git checkout db/schema.rb` – Clucking Turtle Sep 18 '13 at 21:24
  • No I pull from development, which has `enable_extension`. In production, I do the following: `pull`, `migrate`, `git checkout schema.rb` before I am able to `pull` the next time. – Clucking Turtle Sep 19 '13 at 21:49
  • It doesn't seem right to `git checkout schema.rb` every time, that's why it feels I should just ignore `schema.rb` :( – Clucking Turtle Sep 19 '13 at 21:50
  • 2
    I don't believe db/schema.rb is read in either the production or development environments. It's basically a way for the test environment to dump the schema and re-setup when it runs it's tests. More info: http://stackoverflow.com/questions/9884429/rails-what-does-schema-rb-do – Steven Harlow Jul 24 '14 at 16:52

2 Answers2

2

As far as I understood it, the problem is that the auto-generated schema.rb will differ on production and development, and therefore cause changed files in git, because of this extra line.

Is the line generated by the postgres adapter on mac ? If it's been added manually, I'd try to put it somewhere else, maybe in an initializer (where you could switch its use based on the platform via something from here: Detecting Operating Systems in Ruby ).

Community
  • 1
  • 1
Martin T.
  • 3,132
  • 1
  • 30
  • 31
  • The changes generated on production should not be in version control. Nevertheless, if you use different databases in development, a change in that config will cause a different `scheme.rb`, and mess with your versioning. In this case, I'll ignore the `scheme.rb` if it is going to be a derivative file and not manually edited. – jgomo3 Jun 19 '16 at 20:16
0

I would always use the migrations. schema.rb has the downside of being only ruby. If - for some reason - you have plain SQL in your migrations, maybe to use BIGSERIAL instead of SERIAL or so, you will get a problem with schema.rb. Switching to a SQL-based schema-dump only solves part of the problem, leaving possible needed data-corrections or data-seed out of the picture.

kronn
  • 925
  • 11
  • 31