Fix migration for PR 66 #70
Conversation
- Event Model, which previously had all info about the event occurence, becomes EventInstance - a new Event model now contains event identity - event creation workflow happens thorugh the instance--an event should not exist unless we have a record of one of its instances - update specs for changed models and controllers - update feature specs to reflect new workflows - update factories - update related Submission model to communicate with EventInstance instead of Event - fix migration to try to find parent events before creating to avoid unique key issues
|
Just looking at this now.. FYI — didn't have to use |
|
I think I wrote that before resolving the merge conflict in the web app (airport)... which added another commit to the history so it no longer diverged |
|
Yay, merged and shipped!! Thank you, @flyinggrizzly. This was wonderful. Thank you so much for your patience. Going through a few things right now so I really appreciate it. Speak soon, Nadia |
|
Anytime, and no worries! And thank you for your patience with me, and the support and feedback. I’ll poke through some of the other issues in a bit too. And I’ll see you at Bath Ruby! |
|
Oh, yay! Exciting — get to meet my number 1 contributor in the flesh! And thank you for the feedback! As an FYI, I'll be working on the ability to delete submissions and the design for that next, so don't worry about that piece. I've also got to sort out some config stuff like SSL and think about site backups soon. Speak soon! |
Migration now tries to find an Event object before instantiating on
upThis allows migration to continue when an event has multiple instances.
See also #66 (comment)
Steps for verifying migration:
before pulling down latest changes
bin/rails db:rollback STEP=1--this sets it so we have multiple old events with the same name but different yearsafter pulling down latest changes
repeat as above, but the migration will succeed because it will try to find an existing event before attempting to instantiate it