Skip to main content

Refactored Event Ownerships

As services grow, code grows out of its initial purpose. That was the case for event ownership as well at Colloq so when we identified a bug inside the ownership code, we realised that a refactoring of the ownership database model and codebase is necessary—something we long knew but ignored happily.

Until now, event ownership—technically spoken—was just a database column referencing a User from the user table. This was a simple and effective mechanism that worked for a while. But all the codebase we’ve built around grew a lot in the past year and since we show more about the organisers of an event we faced more struggles with the way we treat owners.

That is mainly because we also have a database table for Event Users. This table contains any user that has a relation to an event, for example a user that follows or attends the event but also a user who’s staff of the event. That meant we had two different places where we store user information for an event. In the end it increased complexity in our codebase a lot and user listings would have to be compiled from different sources before we could output them.

We refactored ownership now, so an Event Owner is now a proper Event User in the same database table. And while this decreases performance as the amount of database queries grows with it, the benefits are clearly overweighting that. For the future, we could now also allow multiple owners per event which in certain team constellations might make sense.

Refactoring this took me a full five work days, ~400 additions and ~200 deletions in our codebase over 45 files. A task I wasn’t suspecting to be as big but when I look at the if-conditions we had in our event codebase before and after it, it’s definitely worth all that time and effort.


Want to read more articles like this? Subscribe to the category Engineering or the feed for all our articles.