List of Projects WebsiteOne Features request and design Event Internal design plans (in light of future features)

Event Internal design plans (in light of future features)

Updated about 5 years ago by Jon Engelbert

Definitions:

Event_Template:  A repeating event template, used to generate future event instances. Based on the existing Event model.

Event_Instance:  A single instance of an event, whether past, present, or future. Based on the existing Hangout model.

Why Change?

Presently, the Event model includes recurring event templates, event templates for one-time events, and event instances.  

Event#next_event_occurences generates a collection of (Event, instance start time ) pairs which are used as event instances.

Event#next_event_occurrence returns an Event model instance with a special attribute, next_occurrence_time_attr.  

If nothing else, we should standardize between (Event, instance start time) and next_occurrence_time_attr for these Event instance impostors. But the best solution will be to generate event instances instead of either of these other return types.
 

Yaro and I worked on display future event instances alongside event instances, and we were able to accomplish this with a new Event Presenter class with 5-10 methods to map from the Event class to each of the Hangout (event instance) methods.  Not terrible, but it will be cleaner if the Event template class can generate event instances and those can be used directly.  

With this proposed change, the Event model will be used only for recurring events.  When event instances are needed, the Event model will generate Event instances.  It will be simpler to display upcoming and live and past event instances together, and it will be simpler to query them together.


A diagram of the schema:


(Original document: schema for event templates and instances )

There are two core models:

- Event template (this is based on the existing Event model), which is used to generate event instances from recurring event definitions... i.e.. it is both a model on its own, and a factory class.

The event template will not change much, if at all.  It will include everything that is in the Event model/table presently.

The big change for the Event (Event Template) model is simplification in its responsibilities.  It is now only going to be used to represent recurring event templates.

A new field, Hangouts_created_through, can store the date through which hangouts have been created and stored based on this recurring event template.  I'm not certain that Hangouts_created_through is necessary.

- Event Instance (Hangout), which can have a google hangout URL, and/or a youtube URL.  It will require a new field,  scheduled_start, in order to map it to a specific instance of a recurring event.  Also, it will require a new field, hangout_start, which is the actual start time for the google hangout.  Presently, the created_at field for the record is used for the start time for the google hangout.

The big change to the Hangout(Event Instance) model is its timeline.  Now, Event Instances can exist BEFORE the google hangout starts.

- Modifying and Deleting event instances:

Q1: If the user  deletes an event instance, what will prevent event@next_occurrences from creating duplicate event instances?

A: An event deletion record could be created for the modified instance, and when generating event instances from the event template, instances that have been deleted should not be included in the collection of instances.

Q2:  If the user  modifies an event instance, what will prevent event@next_occurrences from creating duplicate event instances?

A:  All event instances from 'now' through the last modified instance time can be generated and stored, and Hangouts _created_through could be advanced to the datetime of the modified event.  

Better yet, an event deletion record could be created for the modified instance, and when generating event instances from the event template, instances that have been deleted should not be included in the collection of instances.

Q3: For repeating events with no end date, won't we need to create (and store) an infinite number of event instances?  

A: Event instances are only created as needed.  E.g., if the Event (or Hangout) index page needs the next month's worth of event instances, then the Event_Template will be called upon to generate those.  However, they don't need to be stored in the database.  The event instance only needs to be stored in the database when the user starts the event instance's Hangout, which is already being done.  Also, we might allow the user to change the event's time or other parameters, and in this case the future event instance will need to be stored, probably using the same model as the present and past event instance (Hangout).

SRP (single responsibility):  This approach should simplify the models.  

Other considerations.

-  Keep track of event participants:  This can be done the same way for upcoming/live/past event instances with a through association to the users table.

- To store cancelled instances of a repeating event (e.g. client can't attend a weekly client meeting, so it's cancelled), create a new table that stores the start_datetimes of these cancelled event instances, and associate those with the Event template.

- To store modified future instances of a recurring event

Related change to next_occurrences

- Event#next_occurrences will no longer generate collections of {event, time} pairs, but will instead generate a collection of Hangout.

- Event#next_event_occurrence will need to generate a list of something other than Events (I propose that it generates a Hangout)


Revisions

comments powered by Disqus