Best Practice: Using Gems that require model changes

Rails
1

In my particular example, I originally built my app with simple user
authentication just to get it up and going. Since then, I’ve decided to
use Authlogic.

Authlogic requires a few changes to my user model, so my question:

Is it best practice to create a new migration with changes to the
previous User model created, or would you be okay with modifying the
original User file as needed to suit the new parameters of Authlogic?

2

Steve C. wrote:

In my particular example, I originally built my app with simple user
authentication just to get it up and going. Since then, I’ve decided to
use Authlogic.

Authlogic requires a few changes to my user model, so my question:

Is it best practice to create a new migration with changes to the
previous User model created, or would you be okay with modifying the
original User file as needed to suit the new parameters of Authlogic?

Migrations have little to do with Ruby classes, so your question is a
bit meaningless. Migrations are only for DB changes and the bookkeeping
that comes with them.

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

3

Marnen Laibow-Koser wrote:

Migrations have little to do with Ruby classes, so your question is a
bit meaningless. Migrations are only for DB changes and the bookkeeping
that comes with them.

The only reason I’m curious is because my User model was one of the
earlier models that I generated, and it didn’t have fields that
Authlogic uses, such as password_salt and persistence_token.

So when I’m making changes to my User model, is it best practice to go
back and change the original User migration I made, or would it be
better to create a new migration and define the field changes in the new
migration file?

The only reason I see doing the latter would be to have a traceable
history of the evolution of the app, but since this is my first I don’t
know if it’s worth doing that for a change as trivial as this.

I’m sorry if you feel the question is meaningless, but I’m honestly
wondering the best way to do this.

4

Steve C. wrote:

Marnen Laibow-Koser wrote:

Migrations have little to do with Ruby classes, so your question is a
bit meaningless. Migrations are only for DB changes and the bookkeeping
that comes with them.

The only reason I’m curious is because my User model was one of the
earlier models that I generated, and it didn’t have fields that
Authlogic uses, such as password_salt and persistence_token.

So when I’m making changes to my User model, is it best practice to go
back and change the original User migration I made, or would it be
better to create a new migration and define the field changes in the new
migration file?

The only reason I see doing the latter would be to have a traceable
history of the evolution of the app, but since this is my first I don’t
know if it’s worth doing that for a change as trivial as this.

I’m sorry if you feel the question is meaningless, but I’m honestly
wondering the best way to do this.

Could you show us the “original User migration” that you made?
I’m guessing what you’re looking for is some kind of VCS - Versioning
Control System, such as git, subversion, bazaar, cvs… Anything that
keeps track of the changes made to files over time.

5

Steve C. wrote:

Marnen Laibow-Koser wrote:

Migrations have little to do with Ruby classes, so your question is a
bit meaningless. Migrations are only for DB changes and the bookkeeping
that comes with them.

The only reason I’m curious is because my User model was one of the
earlier models that I generated, and it didn’t have fields that
Authlogic uses, such as password_salt and persistence_token.

So when I’m making changes to my User model, is it best practice to go
back and change the original User migration I made, or would it be
better to create a new migration and define the field changes in the new
migration file?

Don’t change your old migrations. That defeats the purpose of having
them.

(Actually, some people advocate periodic consolidation of old
migrations, but that’s a bit different.)

The only reason I see doing the latter would be to have a traceable
history of the evolution of the app, but since this is my first I don’t
know if it’s worth doing that for a change as trivial as this.

It’s worth doing. And as far as a traceable history goes: you are
using version control, right?

I’m sorry if you feel the question is meaningless, but I’m honestly
wondering the best way to do this.

I thought the question was meaningless because it sounded like you were
trying tk use the migration on the User class, not the users table.

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

6

Aldric G. wrote:

Could you show us the “original User migration” that you made?
I’m guessing what you’re looking for is some kind of VCS - Versioning
Control System, such as git, subversion, bazaar, cvs… Anything that
keeps track of the changes made to files over time.

Sure; it’s as simple as:

class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :login
t.string :password
t.string :firstname
t.string :lastname
t.string :email

  t.timestamps
end

end

def self.down
drop_table :users
end
end

The changes I needed to make was to change:

:password > :crypted_password

and to add a couple of additional fields.

So my original question would be should I just make the changes, revert
back to a previous version of the database using rake db:migrate
VERSION=x, then rake db:migrate to come back to the most latest which
includes the new changes.

or…

Make a new migration file and make changes to the database that way.
I’m probably making this more confusing that it needs to be, to be
honest.

7

Steve C. wrote:
[…]

The changes I needed to make was to change:

:password > :crypted_password

and to add a couple of additional fields.

So write that in a new migration.

So my original question would be should I just make the changes, revert
back to a previous version of the database using rake db:migrate
VERSION=x, then rake db:migrate to come back to the most latest which
includes the new changes.
No! If you do that, then you’ll lose your data on the rollback.
Migrations are designed to be run against (say) your production DB
without losing data.

or…

Make a new migration file and make changes to the database that way.

Yes! This is the proper way.

I’m probably making this more confusing that it needs to be, to be
honest.

You certainly are. Why are you trying to avoid using migrations as they
were designed to be used?

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

8

Marnen Laibow-Koser wrote:

You certainly are. Why are you trying to avoid using migrations as they
were designed to be used?

I guess the concept hadn’t sunk in. I understand now how to get it
done, but the idea of what they were and how to use them effectively
really hasn’t solidified itself in my brain. In short: I have plenty of
learning to do.

My thought process was, “Ok. So I want to use Authlogic, and now I have
to make changes to my User fields in my database. Do I just make a new
migration or can I just make the changes in my old User migration? Let
me just see if this works (begin changing old user migration).”

Well it works, but there goes all my data (it was just test stuff
anyway). Lesson learned. This definitely cannot happen once I have
sensitive data on my hand in a production environment. I was curious to
see what happened, and now that I see, you can bet I won’t do that
again, lol. :slight_smile:

Thanks for your help Marnen. I appreciate your patience.

9

Marnen Laibow-Koser wrote:

Don’t change your old migrations. That defeats the purpose of having
them.

Thanks. That’s what my gut was telling me to do, but merely changing
the migration seemed a quicker (but dirtier) way to update my database.
I’ll go back and make the changes you suggest, and make sure I just
create a new migration.

It’s worth doing. And as far as a traceable history goes: you are
using version control, right?

No, unfortunately. I’m very new to developing in rails, and heard of
using Git. I understand the theory of what it is but have no clue on
how to use it. I’m thinking of paying the $9 to learn how to use it at
Peepcode, unless you have some advice on an alternate place to learn?

10

Steve C. wrote:

Marnen Laibow-Koser wrote:

Don’t change your old migrations. That defeats the purpose of having
them.

Thanks. That’s what my gut was telling me to do, but merely changing
the migration seemed a quicker (but dirtier) way to update my database.
I’ll go back and make the changes you suggest, and make sure I just
create a new migration.

It’s worth doing. And as far as a traceable history goes: you are
using version control, right?

No, unfortunately. I’m very new to developing in rails,

Version control is essential to any development environment. This is
not specific to Rails.

and heard of
using Git.

Good choice, though it may be slightly harder to learn initially.

I understand the theory of what it is but have no clue on
how to use it.

Then learn! Never do any development at all unless you’ve got version
control and tests in place.

I’m thinking of paying the $9 to learn how to use it at
Peepcode, unless you have some advice on an alternate place to learn?

I learned to use it from the instructions at the Git website and man
pages, and from searching the Web when I had questions.

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

11

Steve C. wrote:

Marnen Laibow-Koser wrote:

You certainly are. Why are you trying to avoid using migrations as they
were designed to be used?

I guess the concept hadn’t sunk in. I understand now how to get it
done, but the idea of what they were and how to use them effectively
really hasn’t solidified itself in my brain. In short: I have plenty of
learning to do.

Here’s a concise explanation. Each migration file contains whatever is
necessary to transform the DB from one consistent state to the next.
That could be table manipulations, data munging, whatever. The idea is
that if the DB is in a consistent state and you run one migration file,
when you finish, the DB will again be in a consistent state – and if
you got it wrong, you can roll back and try again.

My thought process was, “Ok. So I want to use Authlogic, and now I have
to make changes to my User fields in my database. Do I just make a new
migration or can I just make the changes in my old User migration? Let
me just see if this works (begin changing old user migration).”

Well it works, but there goes all my data (it was just test stuff
anyway). Lesson learned. This definitely cannot happen once I have
sensitive data on my hand in a production environment. I was curious to
see what happened, and now that I see, you can bet I won’t do that
again, lol. :slight_smile:

Indeed. Glad you got that out of your system. :smiley:

Thanks for your help Marnen. I appreciate your patience.

You’re welcome!

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]