I’ve never used migrations, and everyone on IRC calls me crazy because
of that. Still have yet to get any real responses as to why I’m crazy
though…
I’m writing a new app now, but I don’t know the whole db schema for
the entire app. Go figure, that’s just how it works. I’ll add a
bunch of tables, edit tables, etc as the app chugs along. Figured
that migrations would be a good way of handling this, compared to
editing a schema file and having to drop and create the database every
time. Migrations are also apparently good for updating production
DBs, where you obviously can’t just drop them.
My question is how to get started then…ideally I’d do everything in
the migrations as opposed to having a SQL create script, because I
don’t want to have to maintain it in two places. Can I do everything
with migrations that I can with SQL, such as create serial columns and
custom sequences in PostgreSQL? How about foreign key constraints?
I’m just unable to find the docs for migrations really, because I’ve
yet to find a lot of info on them. Some stuff in the wiki, but
nothing that answers my questions. They seem to be very popular, but
surely nobody’s using them if they don’t have the ability to handle
things that everyone uses in their databases (auto_incremement in
MySQL, etc). Can anyone answer these questions, or point me to a
source for more info?
My question is how to get started then…ideally I’d do everything in
the migrations as opposed to having a SQL create script, because I
don’t want to have to maintain it in two places. Can I do everything
with migrations that I can with SQL, such as create serial columns and
custom sequences in PostgreSQL? How about foreign key constraints?
You can use any methods in ActiveRecord::SchemaStatement [1] to update
your schema. Note the #execute method - it allows you to execute
arbitrary SQL.
If you target PostgreSQL, and your production DB is also on PSQL, you
can use #execute to setup serial columns and custom sequences.
On Fri, 2005-11-11 at 08:38 +0100, Sascha E. wrote:
Still doesn’t explain why he has to use migrations for it. I think in Pat’s
case, when you just execute arbitrary db specific statements it might not
be as useful as with let’s say Typo, where you target more than one
database and compromise on a feature set which works with all of them. In
that case, all can use the same schema file.
Sascha E.
This could work a few ways. As a PostgreSQL user, I find myself adding a
few extra non-My$QL features at times. What Migrations provides is a
nice framework and methodology for handling incremental changes to my
schema. I’m currently using a combination of #create_table and #execute
methods to achieve my evolving database schema. (things change)
Having one huge schema file is nice to have for that initial import…
but as changes occur, tracking what changed… in what order is nice to
have a record of. So you can do this yourself through your own method of
managing changes… or use the ever-so-convenient Migrations to stick
these changes in. You don’t have to use it… but I would highly
suggest that you do… or model your home-brewed process after it.
I’m writing a new app now, but I don’t know the whole db schema for
the entire app. Go figure, that’s just how it works. I’ll add a
bunch of tables, edit tables, etc as the app chugs along.
Which, IMHO, is how you should do it in most cases. YAGNI and all
that jazz.
My question is how to get started then…ideally I’d do everything in
the migrations as opposed to having a SQL create script, because I
don’t want to have to maintain it in two places. Can I do everything
with migrations that I can with SQL, such as create serial columns and
custom sequences in PostgreSQL? How about foreign key constraints?
AFAIK, you can do anything with migrations that you would do
otherwise. If what you want to do isn’t implemented in the schema DSL,
you can always execute raw SQL using the #execute method within your
migration:
class ExampleMigration
def up
execute “any sql you want”
end
end
I’m just unable to find the docs for migrations really, because I’ve
yet to find a lot of info on them.
Still doesn’t explain why he has to use migrations for it. I think in
Pat’s
case, when you just execute arbitrary db specific statements it might
not
be as useful as with let’s say Typo, where you target more than one
database and compromise on a feature set which works with all of them.
In
that case, all can use the same schema file.
Sascha E.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
