Creating a calendar in OTP

Why is finding conflicts sluggish in the Rails app?

Heh, actually I have no idea - I’m actually not super familiar with Rails.

Honestly, I’m more focused on “how to think about a scheduling calendar within OTP” than specifically fixing problems with the Rails app, though that is what sort of sparked this.

I couldn’t think of a reason for the finding or resolving of conflicts to be difficult. With a liberal use of PostgreSQL’s OVERLAP operator (PostgreSQL: Documentation: 9.0: Date/Time Functions and Operators) it should be fairly trivial to do.

Now regarding this OTP app idea of yours. What kind of granularity would the processes have? I can’t think of a level of granularity that would actually work for this example, hence why I ask. You couldn’t have a process per hour because then what if an event spans multiple hours? You can scale that idea up to days, weeks and months.

I see you suggested days, but what about an event that spans over two days?

I am not entirely sure that an OTP app here would work, but I am not an OTP expert by any stretch of anyone’s imagination. I’m open to being proven wrong here.

What if each future event is a process? To check for conflict, send a message to all events, those with conflict will report back, you can then cancel event that are not prioritized.

Postgres has range data types so it’s even simpler you can even build a unique index that will enforce no overlapping bookings

Nice I wasn’t aware of this until now.

How far into the future would you be reasonably expected to check? What if there was an event the day after the last day you checked up to?

To infinity and beyond Recurring events will implement conflict check differently and only one process exists, one-off event is one process. I think this design makes sense if you want to do something fancy like weighted job scheduling which is a pretty classic problem.

My two cents

Groups and registers ! Each event is an independant process. You register them to a group/register for the room. And when a new event come, you can just broadcast to all event asking for conflicts. They are optimisations that can be done, like also having a “leader” process per room that handle an aggregated copy of the data, etc etc.

I think @Trevoke is discovering that lately through his side project.

Haha, yeah, I am.

Having every event an independent process does offer significantly more freedom overall, although it does mean a change in perspective and tooling.

It turns out Google Calendar’s current interface can show you some reasonable approaches to it, by limiting the time range in which it will suggest times for the meeting: if you’re concerned about every event ever being a process, you can also just spawn the ones you’re likely to need.

As for me, I’m stuck with a failing test over here: (EXIT) no process: the process is not alive or there's no process currently associated with the given name, possibly because its application isn't started