The "where is it?" thread

[Tony Olivo]

Hey all,

So I started working on the visit model today. One of the variable names was datetime (which is also a keyword), so as a matter of clean up, I was going to change that variable to "arrived_at". I'm trying to get the tests running, but it would seem the MySQL database has no "arrived_at" column. I thought I caught everything in the YML files, and modified schema.rb in the db folder. After I rake db:migrate or rake db:create:all it looks like schema.rb gets overwritten. I'm not sure where to look for the rake actions to try to go after the problem.

I'll keep looking into it, but do let me know (and I'm sure you know) where to do the right thing.

Also, I will be committing to the fork github.com/Thav/freehub

-Tony

[J.P. Lien]

Tony,

Rails handles db changes with "migrations". The source files for these
are in db/migrate. Look at what's in there and you will catch on pretty
quickly. For more in depth info look at the Rails documentation for
ActiveRecord::Migration. One thing to note is that there are two
methods for every migration, "up" and "down". Up makes the changes you
want, and down reverses them. This allows rake to take the DB to any
version in the project's history.

To make your own migration, do `script/generate migration <name>` from
the root folder.

J.P.

> <http://github.com/Thav/freehub>
>
> -Tony
>
> --
> You received this message because you are subscribed to the Google
> Groups "Freehub Users" group.
> To post to this group, send email to freehu...@googlegroups.com.
> To unsubscribe from this group, send email to
> freehub-user...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/freehub-users?hl=en.

[Tony Olivo]

Hey JP, I think I changed everything in the db folder under migrations
to be what I wanted. Maybe it's a matter of clearing the databases and
trying again? Is there a db:destroy that's the analogue to db:create?
You can see where I left off at github.com/Thav/freehub. (Took me a
little while today just to get that set up, so little time is spent
developing when I break everything!)

-Tony

[J.P. Lien]

Tony,

I'm not sure exactly what you did, but you're not supposed to edit old
migrations, only to create new ones. Editing the old ones breaks the
reversibility of changes.

The DB keeps track of its migration level, so if you run a rake
db:migrate without creating a new migration it will see that it's at the
highest level and do nothing. If you want to rerun old migrations you
can `rake db:migrate VERSION=0`, which will take it back down to
nothing, and then `rake db:migrate` to do them again.

J.P.

[Tony Olivo]

Ah ha, I think I understand now. That's why there is the year of birth
migration. So I should revert my db/migrate/004_create_visits.rb (I
think that's the only one I changed), and create a new migration that does
remove_column :visits, :datetime
add_column :visits, :arrived_at
to replace that column, and do the opposite for self.down. I'll try that
when I get home tonight.

I read somewhere that using the padded zeros numbering for migrations
was a little tricky with multiple developers, and that timestamps were
recommended. I'll just continue with 011 at the moment, but wanted to
see if there was any reason to switch. It doesn't seem like we'd all be
changing the migrations at once though.

If anyone wants I can add you as collaborator on my fork.

Thanks again,
-Tony

[J.P. Lien]

Yeah, Rails officially switched from serial numbering to time/date
stamping at some point; I'm not sure exactly where. If you use
script/generate to make a new migration file, it will name it
according to the new convention, saving you the trouble.

J.P.

[Alon Salant]

> migration.  So I should revert my db/migrate/004_create_visits.rb (I think
> that's the only one I changed), and create a new migration that does
>    remove_column :visits, :datetime
>    add_column :visits, :arrived_at
> to replace that column, and do the opposite for self.down. I'll try that
> when I get home tonight.

Nope. You should create a new migration called something like 'rename
visit datetime to arrived_at' that has:

rename_column :visits, :datetime, :arrived_at

Migrations get run on the production database with new deploys. If you
remove and add the column, we will lose all existing data for the
datetime column for all visits. So you need to rename.

I assume you are also planning to add a column for the end of the
visit. You could do that in the same migration. Maybe it would then be
called something like 'add visit start and end'.

I also think 'start_at' and 'end_at' may be better names as they would
then line up with 'start_on' and 'end_on' for Service.

It's definitely worth doing some reading about Rails migrations as
they are a core component of the iterative development style
encouraged by the framework.

Alon

[Tony Olivo]

All right, I will try to get a little more familiar with it. Thanks you guys for being patient with me, but now this is logged on the list for the infinite memory of the internet to serve to our future developers!

With regards to the start, end etc, I was thinking there would be three times. When the person arrived, as this would maintain the queue of services to be rendered (could maybe use the created_at inherited attribute, or maybe this is a bad idea), a start_at time that means the person has actually been let into the shop to start volunteering/working on their project, and the end_at time for signing them out. I will try that and see where I get. I'll use the generate script as JP suggested.

Thanks,
-Tony

[Tony Olivo]

Ok, got the migrations right and cleared up the test errors I was having. There are three failures I get still that seem to be present in the revisions before I forked. I can't quite figure them out yet. One having to do with chain_finders (don't understand those bits at all yet), another with the visits in range test (I don't agree with either the assertion or the result) and one other I forget. If I get them fixed in the fork I'll let you know.

-Tony

On Mon, Jun 14, 2010 at 12:29 PM, Alon Salant <al...@salant.org> wrote:

[Alon Salant]

Cool. Are you up to date with the rails upgrade to 2.3.5 in trunk?

I wouldn't bother fixing the items you mention until after doing the
upgrade b/c enough changed in the process.

[Tony Olivo]

I seem to be, my fork was from the same version you started the tag branch. I get the same failures when I rake test on the master branch of yours.

  1) Failure:
test_chain_finders(VisitTest) [/test/unit/visit_test.rb:33]:
<3> expected but was
<4>.

  2) Failure:
test_for_organization_in_date_range(VisitTest) [/test/unit/visit_test.rb:19]:
<99> expected but was
<98>.


  1) Failure:
test_visits_for_day(VisitsControllerTest) [/test/functional/visits_controller_test.rb:113]:
<2> expected but was
<3>.

Well, that last failure is different in mine, but those are what I see now.

-Tony

[Alon Salant]

Hmm... those off-by-one numbers make me think there may be some time
zone funkiness going on. I have the fixture data set up to surface
time zone bugs but that may be introducing different behavior based on
your local time. Where are you again?

[J.P. Lien]

I get the same failures in the master branch. Tony and I are both on
Eastern time.

J.P.

[Alon Salant]

Yep. If I set my local machine time zone to east coast I get the same
test failures. I'll check it out.

[Alon Salant]

This should be fixed now in master for you guys.