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

Definitely not.

On 4 March 2010 05:51, Andy J. [email protected] wrote:

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?

       'live'  => 'published on site',
 status.each do |name, display_title|

def self.down
end
http://groups.google.com/group/rubyonrails-talk?hl=en.
http://groups.google.com/group/rubyonrails-talk?hl=en.


Charles A. Lopez
[email protected]

What’s your vision for your organization?
What’s your biggest challenge?

Let’s talk.
(IBM Partner)

To the OP

in plain english, what are you trying to do?

On 4 March 2010 05:32, ct9a [email protected] wrote:

   {
   },
     :updated_by    => 'admin'
     :display_title => display_title

To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected][email protected]
.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.


Charles A. Lopez
[email protected]

What’s your vision for your organization?
What’s your biggest challenge?

Let’s talk.
(IBM Partner)

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.

On 4 March 2010 23:36, Gordon Y. [email protected] wrote:

Assuming an online t-shirt sales application, each order catalogue would
have the following statuses throughout the life of the application.

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.

On 4 March 2010 19:51, Hassan S. [email protected]
wrote:

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 S. wrote:

On Thu, Mar 4, 2010 at 5:18 AM, Marnen Laibow-Koser
[email protected] 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 S. ------------------------ [email protected]
twitter: @hassan

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]