Rajesh Jayaraman

Bitten by an assumption?

Its been a while since I posted on this blog.

Today I had this really long and hard design discussion with the security dude at our company and the architect, 2 guys I respect immensely.

We were discussing some truly arcane way to manage unique event identifiers across a client application that a server must respect. The problem is you have many distinct sets of values each of which can be guaranteed to have unique values within them, but a value is not guaranteed to be unique across these sets.

Like, you are pulling data out of 3 database tables and construct URLs based on their primary keys. Now the problem is these URLs need to be completely unique irrespective of which table they come from. You get the picture?

In one of those blind alleys that such discussions take, we came up with an idea to use a few leading bits of the integer to specify uniquely which table is used and the trailing bits can accomodate the actual ID from the table.

Now, the architect suggests that you may run out of IDs. So I suggested that it is a problem we can take up later and that we won;t have so many IDs. The architect agreed saying that before we get to that kind of ID numbering our database will crash and we will need a different way to store it anyways. The security dude steps in and says, it is a bad idea to depend on IDs being incremented sequentially. Its the kind of thing that comes back to bite you in 2 years. How true!!

To cut a long story short, never make an assumption that is not justified. Or better still, as the bad guy in Under Siege 2 says "An assumption is the mother of all fuck-ups"

blog comments powered by Disqus