Partial Day Blackouts
As co-founder, I wear many hats. One of my favorite hats is that of database architect. No matter how big we get as a company, I think I’ll always want to keep a hand in the database because I enjoy it so much.
So recently while wearing that hat, I was focusing on ways to speed up our GigMasters database. One thing I noticed was that every time a user did a search where they included their event date in the search, it was taking WAY too long to return results. The reason? It was having to jump through hoops to exclude performers who had that particular date blacked out. So I decided to embark on an effort to optimize our black out date logic in our database.
After consulting with Alexis (our manager of web development), I decided that we needed to store this blackout information differently in the database. Rather than storing it with the gig requests, I realized that it would be much MUCH faster to store it in a separate black out table that was much smaller. That way when a site search is being done, it only had to look in the much smaller black out table, rather than the giant gig request table.
But in the process it brought up some really interesting issues…
The main issue was what to do when a performer has two bookings in the same day. Because a performer can only black out an entire day but not part of day, it gets particular complicated when one of those bookings gets moved to a different date.
Here’s why:
Let’s say a performer is booked for two gigs on June 1st. Let’s say he’s booked for one gig which takes place from 1pm – 5pm and then he’s also booked for another that takes place on the same day (June 1st) from 8pm – 11pm. So far so good.
But let’s say for whatever reason, the date of the first gig gets moved to June 2nd at 1pm. So the system needs to move the ‘blackout’ to June 2nd. BUT, this performer still needs June 1st blacked out because of his other gig. So in other words in our current system, whenever the date of an event gets changed, and the performer has that date blacked out, the system always needs to check whether there are other gigs on the old date and if so keep that old date blacked out. When I went to change the way we stored black outs in the database, I realized I needed to preserve this logic in the code. [Ok, I have to give Alexis credit for pointing this out to me] Suddenly, what seemed like a small project became a medium project.
Duh – it’s called Partial Day Blackouts
So you’re probably thinking to yourself, shouldn’t a performer be able to black out part of a day and not the whole day? Yes, yes, yes. It’s definitely on the project list and it will eventually get done, but like anything it’s ‘easier said than done’ or ‘the devil is in the details’ (take your pick)
The complication again goes back to how to handle scenarios where the performer has multiple bookings on the same day. Referring back to our original example, let’s say we offer partial day blackouts and the performer has two gigs on June 1st - one from 1pm to 5pm and another from 8pm to 11pm. Because he needs to leave time for travel, set up, and a chance to catch dinner between gigs, he might decide he wants to black out noon to midnight. Now let’s again say that the earlier day’s event for whatever reason gets moved to June 2nd. Now what? The system wouldn’t know what to do with the June 1st noon to midnight blackout period. The performer would have to go back in and reconfigure his blackout periods manually. Now we’ve shifted all that complexity to the performer (and some feel our system is already too complicated). The point here is that when we do finally embark on implementing partial day blackouts, we have to do it in a way that is intuitive, yet functionally rich.
So as you can see “blacking out” is hard to do. It was a lot easier to do in college, that’s for sure!
So recently while wearing that hat, I was focusing on ways to speed up our GigMasters database. One thing I noticed was that every time a user did a search where they included their event date in the search, it was taking WAY too long to return results. The reason? It was having to jump through hoops to exclude performers who had that particular date blacked out. So I decided to embark on an effort to optimize our black out date logic in our database.
After consulting with Alexis (our manager of web development), I decided that we needed to store this blackout information differently in the database. Rather than storing it with the gig requests, I realized that it would be much MUCH faster to store it in a separate black out table that was much smaller. That way when a site search is being done, it only had to look in the much smaller black out table, rather than the giant gig request table.
But in the process it brought up some really interesting issues…
The main issue was what to do when a performer has two bookings in the same day. Because a performer can only black out an entire day but not part of day, it gets particular complicated when one of those bookings gets moved to a different date.
Here’s why:
Let’s say a performer is booked for two gigs on June 1st. Let’s say he’s booked for one gig which takes place from 1pm – 5pm and then he’s also booked for another that takes place on the same day (June 1st) from 8pm – 11pm. So far so good.
But let’s say for whatever reason, the date of the first gig gets moved to June 2nd at 1pm. So the system needs to move the ‘blackout’ to June 2nd. BUT, this performer still needs June 1st blacked out because of his other gig. So in other words in our current system, whenever the date of an event gets changed, and the performer has that date blacked out, the system always needs to check whether there are other gigs on the old date and if so keep that old date blacked out. When I went to change the way we stored black outs in the database, I realized I needed to preserve this logic in the code. [Ok, I have to give Alexis credit for pointing this out to me] Suddenly, what seemed like a small project became a medium project.
Duh – it’s called Partial Day Blackouts
So you’re probably thinking to yourself, shouldn’t a performer be able to black out part of a day and not the whole day? Yes, yes, yes. It’s definitely on the project list and it will eventually get done, but like anything it’s ‘easier said than done’ or ‘the devil is in the details’ (take your pick)
The complication again goes back to how to handle scenarios where the performer has multiple bookings on the same day. Referring back to our original example, let’s say we offer partial day blackouts and the performer has two gigs on June 1st - one from 1pm to 5pm and another from 8pm to 11pm. Because he needs to leave time for travel, set up, and a chance to catch dinner between gigs, he might decide he wants to black out noon to midnight. Now let’s again say that the earlier day’s event for whatever reason gets moved to June 2nd. Now what? The system wouldn’t know what to do with the June 1st noon to midnight blackout period. The performer would have to go back in and reconfigure his blackout periods manually. Now we’ve shifted all that complexity to the performer (and some feel our system is already too complicated). The point here is that when we do finally embark on implementing partial day blackouts, we have to do it in a way that is intuitive, yet functionally rich.
So as you can see “blacking out” is hard to do. It was a lot easier to do in college, that’s for sure!
Comments
Post a Comment