Design Question: How would you create a recurring event system?

Question

If you were commissioned to create an event planning system that supports recurring events, how would you do it? How do you deal with deleting a recurring event? How could you see when future events will occur?

i.e. When creating an event, you can select "repeat daily" (or weekly, annually, etc.).

One design per answer, please. I'm used to Ruby / Rails, but I use what you want to express.

I was asked about this at the interview and could not come up with a really good answer that I liked.

Note: has already been asked / answered here. But I was hoping to get more practical details, as described below:

• If it was necessary to be able to comment or otherwise add data to only one instance of a recurring event, how does it work?
• How will events change and delete?
• How do you expect future events to happen?

Answer 1

I started by implementing some temporary expression as stated by Martin Fowler . This will take care of figuring out when the scheduled item should happen. This is a very elegant way to do this. What I finished was just the result of what is in the article.

The next problem was figuring out how to store expressions in the world. Another problem is when you read the expression, how do they fit into a less dynamic user interface? There was talk of simply serializing expressions in a BLOB, but it would be difficult to go through the expression tree to find out what that meant.

The solution (in my case) is to store parameters that correspond to a limited number of cases that the user interface supports, and from there use this information to generate temporary expressions "on the fly" (can be serialized when created for optimization), Thus, the Schedule class ends in that it has several parameters, such as offset, start date, end date, day of the week, etc .... and from this you can generate temporary expressions to do the hard work.

Regarding the availability of task instances, there is a “service” that generates tasks for N days. Since this is integration with an existing system, and all instances are necessary, this makes sense. However, such an API can be easily used to predict repetitions without saving all instances.

Answer 2

I had to do this before when I was managing the end of the project database. I asked that each event be stored as separate events. This allows you to delete only one event or you can move the range. It is much easier to remove multiples than trying to change one occurrence and turn it into two. Then we were able to create another table in which there was simply an identifier recurrenceID containing information about the repetition.

Answer 3

@Joe Van Dyk asked: "Could you look into the future and see when there will be upcoming events?"

If you want to see / display the next n events of an event, they would have to either a) be calculated in advance and stored somewhere, or b) would be calculated on the fly and displayed. That would be the same for any evening frame.

The disadvantage of a) is that you have to put a limit on it, and after that you have to use b). It’s easier to just use b) to get started.

The planning system does not need this information, it just needs to know when the next event.

Answer 4

When saving the event, I would save the schedule to the repository (let it have " Schedules "), and I would calculate when the event should have started next time and save it also for the instance in " Events ". Then I will look through " Events " and find out when the next event was supposed to happen and sleep until then.

When the application "wakes up", it will count when the event should happen again, save it in " Events " and then execute the event.

Repeat.

If an event is created during sleep, the sleep is interrupted and recounted.

If the application starts or restores from a sleep event or similar, check " Events " for past events and act accordingly (depending on what you want to do with missed events).

Something like this will be flexible and will not require unnecessary processor cycles.

Answer 5

On top of my head (after reviewing a couple of things when entering / thinking):

Determine the minimum required repeat resolution; how often does the application work. Maybe it's daily, maybe every five minutes.

For each recurring event, keep the most recent runtime, interval, and other properties, such as expiration time, if desired.

Each time the application starts, it checks for all events, comparing (today / now + recurrenceResolution) with (recentRunTime + runInterval), and if they match, fire this event.

Answer 6

When I wrote a calendar application for myself, many years ago, I simply stole the scheduling engine from cron and used it for recurring events. for example, something that happens on the second Saturday of every month, except January, will include the instruction "repeat = * 2-12 8-14 6" (every year, months 2-12, the second week runs from 8th to 14th and 6 on Saturday because I used 0-based numbering for the days of the week).

Although it is fairly easy to determine if an event occurs on any given date, it is not able to handle the repetition of "every N days," and is also less intuitive for users who are not compatible with Linux.

To deal with unique data for individual instances of events and delete / reschedule, I simply tracked how events outside events were calculated and the resulting events are stored in a database, where they can then be changed, moved or deleted without affecting the original current information about events. When a new recurring event was added, all instances were immediately calculated before the current “last settlement” date.

I am not saying that this is the best way to do this, but it is a way, and one that works well within the limitations that I mentioned earlier.

Answer 7

If you have a simple recurring event, such as daily, weekly, or a couple of days a week, what happened with the use of buildt in scheduler / cron / at functionallity? Creating an executable / console application and setting up, when to start it? No complicated calendar, event or time.

:)

// W