How do we share variables in a given data migration?
Personally, in your case I’d declare it as a constant instead of a variable at the class level.
If it were a constant you’d never be able to change the value. Is that truly intended?
Definitely not.
To the OP
in plain english, what are you trying to do?
I want to add default fact data to a given database table.
Assuming an online t-shirt sales application, each order catalogue would have the following statuses throughout the life of the application.
- ‘details’
- ‘fitting_profile’
- ‘live on site’
- ‘sold out’ thank you.
It would be worth your time to look at using a state machine then. Either roll your own (it's a fairly simple pattern), or install AASM (Acts As State Machine) to get going very quickly.
So do I -- but migrating down multiple levels and back up has never entered the picture.
Good for you. So you never need to migrate; so you never have migration troubles. However, those people that do migrate (and not everyone does *exactly* the same thing as you), might occasion some problems if they put data access in their migrations. You've asked for examples, and then dismiss them when they're given rather than understanding that different situations exist for different people.
What circumstances require that?
Yesterday I had to work on a project I had never worked on before on this computer; after cloning from the repository, I had to run migrations up.
And yet I still fail to see the evidence supporting this as a "convention", especially given that the API includes examples of using migrations to *change data*, *not* just structure.
Just because it's possible doesn't mean it's good. There's lots of things the documentation describes; it tells me all about how I can use different table names and primary keys for models... but these are generally *bad* as they risk causing unexpected results as development goes on, especially if not all the developers that come to the code during its live realise you've deviated from the conventional practices (but are there for when you *have* to use them - that pesky legacy table that needs to be integrated, but can't be refactored).
To me, using models in migrations is the same; and emergency tool; even the example you linked to shows it as being used to alter existing data, not seed the DB. If a migration I wrote caused me to *have* to alter existing data, then I'd do the minimum I had to - as Rob's example showed - to get it working, but I *wouldn't* use my normal models, as as stated before, I couldn't guarantee that in six months time that model would validate correctly for the data in my migration at that point - or even whether the model existed!
Just because. Sweet ${DEITY} I give up.
No, not "just because" - not like a parent forbidding behaviour for
the sake of it; but the general acknowledgement that when most people
have to complete a task, they try to do it in a way that makes it
easiest for them, and for the people that come after them. If someone
else chooses to do it differently (either to be awkward; because
they're curious; or even that they don't know better), that's fine, if
a little annoying/frustrating 
To be honest, I give up too. Because I answered your queries patiently, yet you don't seem to acknowledge that there might be things that work for you that might be seen as bad practice in the broader community. If you want to continue the discussion, then drop me a line offlist.
Hassan Schroeder wrote:
However, your original example is problematic. You appear to be using migrations for seed data. This is a terrible idea.
Why?
For several reasons. The two most compelling for me are as follows.
* First of all, it's conceptually wrong. Migrations are about the database *schema*, not the data. Each migration file should contain whatever is necessary to bring the schema from one consistent state to the next. Those schema changes may include munging the existing data to fit the new schema's representation, but they can never include seed data. Once they include seed data, migrations step outside their proper role of defining the schema.
* Second, putting seed data in migrations forces you to initialize new installations by running all your migrations starting from zero. This is a known bad practice, and I think even members of the Rails core team recommend against it; in general, it's better to set up a new installation by running rake db:schema:load, but if your seed data is in your migrations, you can't do that.
I can think of no good reasons to put seed data in migrations, and many good reasons not to. Conclusion: don't to it.
-- Hassan Schroeder ------------------------ hassan.schroeder@gmail.com twitter: @hassan
Best,
