Editing Migrations table

Most of my migrations are by number, not timestamp, but 5 or 6 of them
(the most recent) are with timestamp. These I want to move to number
based, and now I want to forward the migration table to the appropriate
number. How do I force the table to update without actually running the
migration, or should I migrate down to 5 or 6 ago (before timestamp) and
then migrate up again with numbers?

Tyler Smart wrote:

Most of my migrations are by number, not timestamp, but 5 or 6 of them
(the most recent) are with timestamp. These I want to move to number
based, and now I want to forward the migration table to the appropriate
number. How do I force the table to update without actually running the
migration, or should I migrate down to 5 or 6 ago (before timestamp) and
then migrate up again with numbers?

You don't want to do any of this. Timestamped migrations are the
default in Rails, and there's really no good reason to avoid there use
AFAIK. What's your ultimate goal?

Best,

Hi Tyler,

Tyler Smart wrote:

Most of my migrations are by number, not timestamp, but 5 or 6 of them
(the most recent) are with timestamp. These I want to move to number
based, and now I want to forward the migration table to the appropriate
number. How do I force the table to update without actually running the
migration, or should I migrate down to 5 or 6 ago (before timestamp) and
then migrate up again with numbers?

The answer to your question is yes: migrate down, change the names of
the time-stamped migrations to be number based, then migrate back up.

IME, there are good reasons to avoid time-stamped migrations. The
chief ones are that they allow lazy communication between members of
the development team and poor habits in terms of update before commit.
If you use number-based migrations you will catch problems at the
rake db:migrate level. Using time-stamped migrations you'll not catch
them until your tests or your users do: a much more time-intensive
debugging circumstance. I'm not saying there aren't situations where
time-stamped migrations aren't worth the risk. But the fact that you
have a mix of number-based and time-stamped migrations indicates a
possible communication problem. Anything that reduces the need for
proactive communication between team members should be carefully
considered re: the risks.

Just $0.02 from someone with a long history of and current
responsibility for ensuring effective and efficient communication
among the team.

Best regards,
Bill

Bill Walton wrote:

Hi Tyler,

Tyler Smart wrote:

Most of my migrations are by number, not timestamp, but 5 or 6 of them
(the most recent) are with timestamp. These I want to move to number
based, and now I want to forward the migration table to the appropriate
number. How do I force the table to update without actually running the
migration, or should I migrate down to 5 or 6 ago (before timestamp) and
then migrate up again with numbers?

The answer to your question is yes: migrate down, change the names of
the time-stamped migrations to be number based, then migrate back up.

If you're going to do that. But don't do it.

IME, there are good reasons to avoid time-stamped migrations.

Not a one IMHO.

The
chief ones are that they allow lazy communication between members of
the development team and poor habits in terms of update before commit.

How so?

If you use number-based migrations you will catch problems at the
rake db:migrate level. Using time-stamped migrations you'll not catch
them until your tests or your users do: a much more time-intensive
debugging circumstance.

You are making a false assumption here: that every migration in the
codebase eventually gets incorporated into trunk. The advantage of
timestamped migrations is that they let developers try migrations out on
their development branches that don't necessarily get incorporated into
trunk.

For example, if trunk is at version 9, and I make changes in my branch
that require migrations 10 and 11, but the maintainer only takes
migration 11, then he will have to renumber it to 10 before running it,
and that's silly. It also destroys any meaning that the migration ID 10
might have had in determining the database schema.

Timestamped migrations, on the other hand, effectively give a unique ID
to each change to the DB schema, regardless of how many changes come
before. This is the superior numbering scheme.

I'm not saying there aren't situations where
time-stamped migrations aren't worth the risk. But the fact that you
have a mix of number-based and time-stamped migrations indicates a
possible communication problem.

Or a Rails upgrade.

Anything that reduces the need for
proactive communication between team members should be carefully
considered re: the risks.

I'm not sure I agree when it comes to integration issues. Yes,
communication is important, but the more the VCS and build system can
automate, the better, other things being equal. Serially numbering
migrations takes away automatability. Don't do that.

Just $0.02 from someone with a long history of and current
responsibility for ensuring effective and efficient communication
among the team.

Best regards,
Bill

Best,

Hi Marnen,

Bill Walton wrote:

Hi Marnen,

Bill Walton wrote:

IME, there are good reasons to avoid time-stamped migrations.

Not a one IMHO.

You are certainly entitled to your opinion. But knowing as I do that
you have no leadership experience in a software development role, your
opinions on topics like this have no weight.

Best regards and hopes that you'll find a Rails job soon,

I'm in one currently for a Fortune 100 company. Spare me the
condescension.

Bill Walton wrote:

Hi Marnen,

Bill Walton wrote:

IME, there are good reasons to avoid time-stamped migrations.

Not a one IMHO.

You are certainly entitled to your opinion. But knowing as I do that
you have no leadership experience in a software development role, your
opinions on topics like this have no weight.

Argument from authority has no weight either. If you disagree with my
explanation for why I believe numbered migrations are bad, I'd love to
hear and learn from why. Till then, it's all just blowing smoke.

Bill Walton wrote:

Hi Marnen,

Bill Walton wrote:

IME, there are good reasons to avoid time-stamped migrations.

Not a one IMHO.

You are certainly entitled to your opinion. But knowing as I do that
you have no leadership experience in a software development role, your
opinions on topics like this have no weight.

Argument from authority has no weight either. If you disagree with my
explanation for why I believe numbered migrations are bad, I'd love to
hear and learn from why.

I provided my reasoning in the post you're responding to. You
provided no 'explanation' other than that time-stamped migrations are
now the 'rails default'.

Till then, it's all just blowing smoke.

It's very clear from a review of your posts that you're simply playing
with the counter. "I'm the x-highest poster on the Rails list." If
anybody's "blowing smoke" it's you. And I'm going to start making
that sure your record is clear with respect to people who use these
easily manipulated stats to judge a job applicant's stature in the
community.

You are, in my opinion, a threat to the Rails community. You prey on
newbies; chastising, criticizing, and otherwise castigating. That's
wrong. So from now on, when you respond to a post, if it doesn't
offer real assistance, be assured that I will respond with a "marnen
is an asshole. ignore him." Piss me off just a little more and I'll
make a new hobby out of going back into the archives and responding in
retrospect. Ain't technology great? !

Bill

Bill Walton wrote:

You are certainly entitled to your opinion. �But knowing as I do that
you have no leadership experience in a software development role, your
opinions on topics like this have no weight.

Argument from authority has no weight either. �If you disagree with my
explanation for why I believe numbered migrations are bad, I'd love to
hear and learn from why.

I provided my reasoning in the post you're responding to. You
provided no 'explanation' other than that time-stamped migrations are
now the 'rails default'.

Quite wrong. The very post you responded to -- available at
http://www.ruby-forum.com/topic/211974#920846 -- contained a detailed
explanation of why I think that time-stamped migrations are less brittle
in a multiple-developer situation; perhaps you missed the latter half of
the post when you replied to it. If you disagree with anything I said
there, please tell me why -- I will listen with great interest to a
logical argument. I am unimpressed by things like name-calling or
argument from authority.

Till then, it's all just blowing smoke.

It's very clear from a review of your posts that you're simply playing
with the counter. "I'm the x-highest poster on the Rails list."

I have absolutely no idea how many posts I've made here. I'm not
playing with any counter.

If
anybody's "blowing smoke" it's you. And I'm going to start making
that sure your record is clear with respect to people who use these
easily manipulated stats to judge a job applicant's stature in the
community.

You are, in my opinion, a threat to the Rails community.

I really don't think I have enough power in the Rails community to be
any threat to it at all, even if I were engaging in behavior that is
destructive to the community, which I don't believe I am. (I love the
Rails community, and everything I have done in its context has been with
a view to helping it, not threatening it.)

You prey on
newbies;

I don't "prey on" anyone. I try to help anyone I can.

chastising, criticizing, and otherwise castigating. That's
wrong.

What? It's wrong to tell someone that he's falling into common newbie
errors, and to suggest a better way of doing things? When did that
happen? I don't get it.

So from now on, when you respond to a post, if it doesn't
offer real assistance, be assured that I will respond with a "marnen
is an asshole. ignore him."

Interesting that you should do that after saying, in the course of
interviewing me, that my posts on the Rails list had helped convince you
that I knew what I was doing with respect to Rails. Of course, things
can certainly change.

Piss me off just a little more and I'll
make a new hobby out of going back into the archives and responding in
retrospect.

Well, post-stalking is generally considered poor form by most people I
know, but if that's what you want to do, I won't try to stop you.

Ain't technology great? !

Technology is great at making sure the facts speak for themselves.
Name-calling lasts forever on the Internet.

Bill

Best,