Dealing with the Unintended Consequences of Others
This morning my newly re-written Broker was not working. Hmmm... so I look at the logs, and it's not too hard to see that there are timeouts on the emongo driver. This was the driver that I used to get from erlang to (and from) the mongo database. Now all of a sudden, it's giving me timeouts. I had no idea.
When the guys that handle the mongo DB arrived today they said that they reconfigured the mongo DB I was using from a single server to a replica set. This is a fault-tolerant mongo DB setup, and in general, I'm a fan of things like this.
But that's not how today went.
Oh no... turns out the API into a mongo replica set is not the same as a single server, and moreover, the emongo driver doesn't support the replica sets. Fantastic!
So now all the work I just finished has to be re-examined in light of a new erlang-to-mongo driver: erlmongo. This guy is capable of dealing with the single server and replica sets modes of mongo DB. This is good, but the API is very different, and most importantly to me, there are no connection pools. If you want to talk to a database, you have to open a connection to the database and then hold onto it.
Given the realities of erlang and persistent state, this isn't really a possibility. We need to have a module that's a connection pooler, and then be able to set that guy up and let him deal with opening the connections, etc.
So here I am, fixing code I just wrote because some other group decided to change the database into an incompatible format. Lovely. It's unavoidable, as it's their group, and their database, but it's a real pain - right on the heels of just getting it done.