Full-House-UW / fullhouse

Full House: a household management tool
fullhousemanager.com
0 stars 6 forks source link

task migrations #217

Closed natmote closed 11 years ago

natmote commented 11 years ago

migrations for tasks are in.

snuriel92 commented 11 years ago

Holy crap... impressive. But I don't get any of this at all to actually approve your pull request

j3ffml commented 11 years ago

LGTM, and tests all pass. I am comfortable merging this now, but can you write a short description of what the transition does?

natmote commented 11 years ago

yeah for sure. where would you like it? as a comment here, in the wiki? or as comments in the migrations?

j3ffml commented 11 years ago

I think having it in a comment here is good as it's sort of a one-time thing, but it would be good to have as a reference. You can put it in the wiki if you think that's better. Either way, I'll merge this now.

natmote commented 11 years ago

okay:

So basically, I re-added due and assigned, to the tasks model, because we needed those values to transition over. I made them blank, so that the new forms would work while I was testing during the transition (otherwise, the forms don't validate, but no error messages are displayed because those fields don't have corresponding form fields).

Then, I automatically generated a schema migration -- this basically just added the new fields and models, and made whatever other changes @jlowdermilk made, other than removing due and assigned, because I added them back in.

Then, I made a series of data migrations. These are migrations that don't change the table schema, but they do change the data.

The first copied the old assigned field to the participants field in tasks. Before, only a single person could be assigned, but now you can rotate among a group. For tasks that were created before, we want them to have a single participant that is the original assignee. So, this data migration iterates through all tasks, and adds the assignee to the participants list.

The second copied due to first_due. For the old tasks implementation, the due date was (mistakenly) a DateTime, so this migration converts the due DateTime to a Date, and assigns it to first_due.

I noticed that unfortunately, the Tas model gives is_active a default value of False. This means that all of the old Tasks have that set to false when this field is created. Rather than fix the default value and redo all of the above migrations, I decided to just write a migration to change is_active to true for all current tasks.

Next, I removed due and assigned from the Task model (because those are no longer used, and only survived this long for the sake of the migration), and autogenerated a migration to reflect this change.

Lastly, I created TaskInstances for all of the old Tasks.