Best practice: Store or calculate repeating events?

[HipJiveGuy]

Hi there;

Thanks for the great library.... seems really nice and I've got it
integrated and working fine.

I'm building a scheduling application that has repeating events. End
users can enter the repeating events, and I want to be able to show
them a calendar of the events they'd have in a specific month.

I did some test events, and it works as expected for the month in
which I created the events. Note that the only events I'm currently
storing in my DB are the "real" events themselves, along with their
repetition rule. To display a month I query the DB for events that
start in that month, then check to see if any of the events have a
repetition rule and calculate the repeating events for just that
month.

The problem comes up of course when I have a repetition rule that
repeats for more than a single month. Since the event "starts" in a
previous month, I don't find it when I query the DB for events, since
it doesn't start in the current month.

I was thinking that maybe I'll have to generate the repeating events
for a certain time period (say event creation + 2 years) and insert
them into the DB whenever a user edits their repeating events... This
would simplify my code in the long run, I think, and would mean that
I'd simply have to run a scheduled task to generate additions to the
repeating events as time progressed, say once a month or so.

Does this sound right? Or am I'm missing some better approach to this
problem?

Thanks,

Brad

[Neal Gafter]

When the user is looking at a given month in the calendar, you want all events that overlap that month.  For example, if you have a non-repeating event that starts in the previous month and ends on the following month, it overlaps the month that is between.

The way I would do it is get the set of events that (1) start before the end of the month to be displayed, and (2) end after the beginning of the month to be displayed.  For the purposes of this query, repeating events should be considered to start on their first instance and end at the end of their last instance.  If they are repeating "forever", then you can treat the last instance as some date in the far future.

The disadvantage of this approach is that you can end up having to examine every repeating event (e.g. every birthday) on every search.  Expanding the set of repeating event instances works too, but it can be more complicated.

--
You received this message because you are subscribed to the Google Groups "google-rfc-2445" group.
To post to this group, send email to google-...@googlegroups.com.
To unsubscribe from this group, send email to google-rfc-24...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-rfc-2445?hl=en.

[Eric B]

Hi Brad,

For most implementations, I would favor persisting the pattern and calculating the occurrences on demand.  The following things I find cumbersome/less-favorable about an approach where occurrences of a recurring event are persisted:

• A background task is required to build out occurrences on an ongoing basis. 
  
• If event modifications are required, the "store" approach is painful. For example, if you have an event that occurs every Wednesday and the user wants to change it to instead occur every other Tuesday, this is now a lot of data to manage, deleting the existing stored occurrences and recreating new occurrences to store.
  
• There can be latency from the point the user creates a recurring event to the point where they can see/manage the occurrences on the calendar.  
  
• The "two years" is arbitrary.  If this is not accurate and the system requires access to events even further out in the future, the solution can become even more unwieldy.
  

The thing I've found most painful about the calculate approach is reporting.  It's pretty challenging to expose the event pattern data to a SQL-based reporting tool.  It will take post-processing to get the reports to expose the data you want.  If the SQL-based reporting tool does not easily support post-processing, this can be tough to overcome.

Regarding your query missing the recurring events that start prior to the month being viewed:  I agree with Neal... this can be addressed by tweaking the way the viewed-month-range is translated in to a date range  that will pick up the appropriate events.

In summary...  even if you find latency and computing resources to be non-issues, I still find the "store" approach to be fragile, being much more likely to result in real and/or perceived data integrity issues.  It is for these reasons that I favor the "calculate" approach. 

Hope that helps,

Eric

[HipJiveGuy]

Hi guys.... thanks for the responses.... my gut reaction was to build it as calculated, and that's what I originally did.... but i've got a use case emerging that involves being able to search against the events for all users in the system, and for all their events, which would be a large # of calculations to do every time someone did a search..... The calculated approach seems more like an "ideal" to me than a practical approach the more the big use case emerges....hmmmm.... food for thought!

[HipJiveGuy]

Thanks for the feedback.... The examining of every repeating event is
the thing that I want to avoid if possible.... there's a use case i
can see coming where I'll have to search against all users events for
matches, and in that case I'd have to examine the repeating events of
all users for all time... which could get very large! I like the idea
of adding an "end date" to the "real" event as I call it... i'll give
it some more thought!