On Apr 21, 2010, at 3:12 AM, Matt wrote:
On Apr 20, 9:25 am, Pito Salas <[email protected]> wrote:
This maybe too vague a question, but I wonder if there's some
wisdom out
there for me to tap...
Sometimes when I get ready to commit, git says that db/schema.rb has
changed. This is weird, and I think it's because I did a rake
db:migrate.
So my question is, what's the best practice relating to putting
bits of
the database (schema.rb and the databases themselves) into sourc
control. And what's the best practice relating to running a rake
db:migrate after a git checkout of a new branch?
Anyone?
- Pito
Pito,
I'm going to leave the entire db version control question for someone
else, but to answer your question about the schema.rb, if you run a
migration, it will change the structure of the database, which is what
schema.rb keeps track of. Rails will rewrite that file every for every
migration ran to reflect the current structure of the db ( structure
as in tables, column names, indexes, etc... Not data the records
stored in the db ). This file should be checked into git, and like any
file that changes under version control, git will let you know about
the changes and track them.
As your app grows, your migration files will be more prone to hving
problems and shouldn't be used to create / setup the database. The
schema file is much better at recreating the db structure when
starting fresh ( like if you have to scale up your app and create a
new db on another server ). There are rake tasks for this, such as
rake db:reset ( caution, that one will wipe out all data in db), so
read up on them and they can save you many headaches as you have to
move your databases around.
-Matt
Matt, Pito, Marnen, and anyone else,
1. The opinion on whether db/schema.rb goes into the source repository
has changed over time. It is an opinion. (I'll give you some of mine.)
2. When properly written, migration files are not "prone to having
problems" and certainly do not have to get worse over time. The advise
here is to define at least a minimal version of your AR model class
nested within the migration class if you need to do *any* manipulation
at the model level.
3. I think that db/schema.rb does *NOT* belong in the repository.
This is particularly true in a multi-developer environment where
migrations are being initially created on different branches. The
database itself isn't going into the repository after all. If you need
the file, run a rake db:schema:dump or just run migrations. If you
think about why the migration numbering (file naming) was changed from
sequence number to timestamp, you'll realize that the practice of such
"interleaved" migrations was a much bigger pain-point than what to do
about db/schema.rb.
4. Unless you're initializing (inserting) data via migration, running
all the migrations is really not much different than doing a
db:schema:load because all the migrations are operating on empty
tables. (Besides, if you have to "scale up your app", you probably
aren't adding a new empty database, but creating a master-slave or
sharding for performance.)
-Rob
Rob Biedenharn http://agileconsultingllc.com
[email protected]
--
You received this message because you are subscribed to the Google Groups "Ruby on
Rails: Talk" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
