In order to reuse the site every year without clearing out Application's table
every time we need the concept of an event.
Event should be a straightforward model to implement. It will need a name (and
probably a slug, although how that will be utilized is best left to another
issue), a date range for accepting applications, and possibly a cutoff date for
early bird applications (I'm not sure if this will be used for anything
functional, but it's a piece of data we've displayed in the past). We'll
probably need additional fields in the future (e.g., an identifier from the
registration service to create discount codes and/or tickets), but we'll worry
about that when we know who and what that will be.
Event should be registered as a foreign key on Application. In order to ease
the migration, a default event should be created and associated with any
existing applications.
Another nice-to-have would be a way to get the "current" Event when one hasn't
been explicitly specified. Initially maybe this can just be the one created by
the migration; down the road it can look at the dates.
In order to reuse the site every year without clearing out
Application's table every time we need the concept of an event.Eventshould be a straightforward model to implement. It will need a name (and probably a slug, although how that will be utilized is best left to another issue), a date range for accepting applications, and possibly a cutoff date for early bird applications (I'm not sure if this will be used for anything functional, but it's a piece of data we've displayed in the past). We'll probably need additional fields in the future (e.g., an identifier from the registration service to create discount codes and/or tickets), but we'll worry about that when we know who and what that will be.Eventshould be registered as a foreign key onApplication. In order to ease the migration, a default event should be created and associated with any existing applications.Another nice-to-have would be a way to get the "current"
Eventwhen one hasn't been explicitly specified. Initially maybe this can just be the one created by the migration; down the road it can look at the dates.