Calendar Recurrence

the othe disadvantage of the first option is that if the event gets deleted, you have a lot of extra clean up to do. I've noticed that some methods have a recurrance threshold, so you might set the recurrance threshold to 10 then each time you reach the 10th event, you need to create another block of recurrances for that event

There has been discussed before a hybrid approach. Use the one event, but allow canceling or changing details. Is that still in the picture?

Sorry, canceling or changing the details of a specific instance of the event (i.e. meeting gets canceled, moved to a different time/location).

Yes this has been discussed in another thread. I was advocating for a 'copy event' solution.

Let consider real life before deciding on a nice theoretical solution.

I am not aware of an event in my life that would recurse periodically forever AND needs a calendar.

Every day events are useless in a calendar. Every week ? even the mass at the cathedral here changes time 3 or 4 sundays a year. First monday of the month ? kind of meetings that are cancelled during holidays... you get the idea

I'd be curious to hear about an event that would recurse 10 times in a row without a change.

Now let's face the kind of scenarii I face in my clients' websites. 50% or recurring events are 2-3 days events like training courses, exhibitions, etc. Usually there is some change beetween these days, for exemple the program is specific every day or the end time is slightly earlier on friday, etc. Let's make it short : exeptions are the rule.

This is why a think that a 'copy and change' is the best, of course with the GroupID for global deletes or global changes.

The dream calendar would be a GUI where you could just insert an event and clic on several other day to repeat this events. Much easier than the 'repeat until XXX every YYY of the ZZZ ... 'interface

Hope that this pragmatic approach will help find the elegant and usefull solution

Benoit

To me, any solution that is considered flexible would allow you to change the details, or delete any instance of a recurring event.

The approach I prefer is to have one table that contains the Events, and their times, and another table that simply contains the dates and is keyed back to the EventID. I think this is an efficient method that allows the maximum flexibility.

If you want a powerful calendar then you also need repeat every xxx of ...

However since most events that will be added are simpler than that I think you could allow the end users to select their prefered entry screen. an Enterprise user would go right to the powerful screen, while the personal user would default to the I want an event right here screen.

I agree that the ability to send events out 10 years is rediculous. Even more than a year is way more than almost any user would need.
What would be very cool though is if a user could click on a recuring event and make it repeat for another 6 months, or Year with the same repeat pattern.

I concur with many of the previous comments - Recurrence is wonderful, but there are times when you need to override the details of a particular instance of a recurring event or cancel one outright. Perhaps the way is to start out using the recurrence method, then allow for separate event entries that would override the recurrence.

I disagree that this makes for added work when removing a recurring event - just delete based on a group ID or parent ID.

So anythoughts on dealing with efficient checks for clashes in the future when a recurring entry is added?

My solution to this is the following:

- Use a "recurrence" table that stores the pattern, and an exceptions table to store exceptions to the pattern.
- Display "virtual" instances, generated from the "recurrence" table
- If a user clicks on a virtual instance and attempts to edit it, ask them if they want to edit the pattern or the instance
- If pattern, edit the pattern and all virtual instances update automatically
- If instance, call Save on the virtual instance, comitting it as a normal, non-recurring event. At the same time,
- Add an "exception" to the pattern, i.e. the "nth" virtual instance should be delted. Aditionally, the exception entry could point to the edited, saved instance, so if the entire pattern is deleted/modified, the modifed instance could be deleted too.

Come to think of it, the saved virtual (i.e. modified) instance could have a field that points to the pattern it came from. You might be able to get away without having an exceptions table if you could store the "exception number" of that instance.

In most calendars I've seen, if you make a change to an instance, and then modify the pattern, the instance gets totally blown away. You could of course, prompt the user that such an action is going to occur.

When I did something similar rather than storing that the 'nth' occurance of an event was removed I just flagged the date, i.e. if an event recurs each tuesday I just stored the date of that or those particular tuesdays when it did not occur. Similarly my exceptions table is driven by date, not by eventID. It seemed to make sense at the time, all dates are essentially unique anyway.

Recurring Events - Architecture and Suggestions