My Mac tells me its "recurrence" with an 'e' though I have spelled it "recurrance" every chance I've had so far... :D

So is the idea that

• user makes an event, marked as recurring, that gets phid X
• for each recurrence, there's another event row, and it gets instanceofEventPHID

? ...works for me if I am grokking this right, though I'd probably differ heavily to the CTO and pick his brain first if I was building this. :D

I guess this will come in a future diff, but how will the recurring events get populated? I can wait patiently on that bit but that's some exciting tech right there.

Darn, I think you're right!

I think the general direction that I was thinking of heading towards is this:

• User creates an event and marks it as recurring. This creates an entry in the event table with the recurring flag and some other information about the recurring event like the frequency of the events and an optional end date for the sequence. No events are pre-generated by this.
• When a query is executed on a date range, all recurring events are returned with the query and all recurring events that fit the range will generate "ghost" events that will look like actual events from the table, but will be mere illusions.
• If a user decides to edit an instance in the sequence (a ghost event), an actual event will be generated under the hood and all updates applied to the new event. Then, the index of that replaced ghost event and the PHID of the original recurring event will be added to the new event, so that we know to not draw that ghost event with that index in the future, because a replacement event will already be in the query result list.
• Most changes to the original recurring event will be allowed except any changes related to the actual scheduling. So description, name, invitee, etc updates will be applied just fine, but rescheduling the event in any way will prompt the user to cancel this recurring sequence and create a new one. Currently, Google allows rescheduling of recurring events, but is very clear that unexpected loss of sequence instance edits might happen. Since unexpected data loss is far worse for us than simply creating a new event, I thought maybe this is a reasonable approach.

There are some edge cases that still need way more thought, but I thought to start in this direction and see how far I get.