how to share variables in data migrations (up/down)

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 :slight_smile:

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.


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 ------------------------
twitter: @hassan