On Mar 4, 2010, at 12:14 PM, Michael Pavling wrote:
On 4 March 2010 16:50, Hassan Schroeder <[email protected]>
wrote:
On Thu, Mar 4, 2010 at 8:31 AM, Ivan Nastyukhin <[email protected]>
wrote:
Because migration for definition structure and manage it.
Just repeating it doesn't make it valid. Again, *why* do you think
that?
Migrations are a "point in time" reference about the structure of a
database.
If they alter *data* then they are binding tightly to the models - and
you can no longer have a later migration that adds/removes/renames
columns, because those columns will be set in the data in an earlier
migration.
Similarly, you can now no longer alter your models, because some
migrations rely on the operation of the model at that "point in time"
- if you create a model, with all its validations, field
specifications, etc, and a migration uses that model. If you later try
to change the model by adding or changing a validation, your migration
will no longer work, as it is tightly bound to the old model.
Is that bad enough for you?
So, the solution is to define a point-in-time version of your Model
that is just enough for you to use to accomplish the migration (incl.
seeding data).
For example, if you are only working with the new columns of a table,
you can (and I'll argue you SHOULD!) define an empty class inside the
migration.
class CreateGames < ActiveRecord::Migration
class Game < ActiveRecord::Base
end
def self.up
create_table :games do |t|
t.string :name
t.integer :prize
t.timestamps
end
Game.reset_column_information
Game.create(:name => "Jackpot", :prize => 1000000)
Game.create(:name => "Instant Win", :prize => 100)
Game.create(:name => "Pick 4", :prize => 5000)
end
def self.down
drop_table :games
end
end
If you have later code (and another migration) that, say, validates
that prizes must be a minimum of 500, your migration can find and fix
existing data, but THIS migration will still work.
This reduces the coupling to the current schema which is what
ActiveRecord is going to reflect upon. If you need some of the
functionality from the model, then it should be duplicated here in the
migration.
-Rob
Being "decoupled" (separating things from each other, so that they're
all free to change without breaking other things) is the fundamental
principle of MVC - models do their thing, as do views, as do
controllers - and it's made *deliberately* awkward to mix them up...
because it's *bad*. So keep your migrations away from seed data, and
also separate your tests from fixtures.
Of course this assumes that you're not going back and editing
migrations... but you wouldn't do that, because that's bad too! :-)
--
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 rubyonrails-
[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
.
Rob Biedenharn http://agileconsultingllc.com
[email protected]
+1 513-295-4739
Skype: rob.biedenharn
--
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.
