We're at a kind of critical point in the choose-your-own-adventure of building this system where we need to more completely flesh out what the event system does.
The way I see it we can build events in 2 parts, the first part is creating events in general. I believe that this should require someone of the authority of a hub or greater, and should probably be anchored to some kind of record that makes it easy to find later. To this end its important to now decide who or what runs events.
If we continue with the idea that hubs have seasons, then we need a hub-season model of some description which will have a listing of events that point to it. This model works really well as long as we require all events to always be attached to a hub at some point. At the point that an event needs to be attached to something that isn't a hub, this model falls apart. @gdyoung93 can you please clarify this part.
The second part of events is being able to sign up for them. This is going to be annoyingly the first part of the application that absolutely needs to take place in a transaction. The event itself needs to keep track of how much space it has left, and then the teams that are going need to point to the event. In this way we can deny signups to full events (note I'm sidestepping the entire problem of waitlists with events).
Now its worth taking a critical detour here to decide what goes to an event. If its a wide variety of things (read: things besides teams) then we probably want to have the attendees point to the event. If its a relatively few kinds of things, then we could have the event itself point to its attendees. If we do the latter, then it becomes slightly more expensive to figure out what events a thing is going to since you have to scan the entire event table. I personally like the idea of pointing to the event, rather than pointing to the attendees. This does come with the complication that events need to declare in advance what they will accept. This second option of declaring what the event accepts and doing the pointer to event and decrementing capacity is my preferred option.
The second part of the event system can be done later, but the model of events themselves needs to be done now.
We're at a kind of critical point in the choose-your-own-adventure of building this system where we need to more completely flesh out what the event system does.
The way I see it we can build events in 2 parts, the first part is creating events in general. I believe that this should require someone of the authority of a hub or greater, and should probably be anchored to some kind of record that makes it easy to find later. To this end its important to now decide who or what runs events.
If we continue with the idea that hubs have seasons, then we need a hub-season model of some description which will have a listing of events that point to it. This model works really well as long as we require all events to always be attached to a hub at some point. At the point that an event needs to be attached to something that isn't a hub, this model falls apart. @gdyoung93 can you please clarify this part.
The second part of events is being able to sign up for them. This is going to be annoyingly the first part of the application that absolutely needs to take place in a transaction. The event itself needs to keep track of how much space it has left, and then the teams that are going need to point to the event. In this way we can deny signups to full events (note I'm sidestepping the entire problem of waitlists with events).
Now its worth taking a critical detour here to decide what goes to an event. If its a wide variety of things (read: things besides teams) then we probably want to have the attendees point to the event. If its a relatively few kinds of things, then we could have the event itself point to its attendees. If we do the latter, then it becomes slightly more expensive to figure out what events a thing is going to since you have to scan the entire event table. I personally like the idea of pointing to the event, rather than pointing to the attendees. This does come with the complication that events need to declare in advance what they will accept. This second option of declaring what the event accepts and doing the pointer to event and decrementing capacity is my preferred option.
The second part of the event system can be done later, but the model of events themselves needs to be done now.