bbs.spamgourmet.com

We currently map each feature to a unique prime number and keep track of which features have been enabled by a user by storing the product of the corresponding primes.

This is not very scalable. The product is stored in a bigint and we will run out of space after a few more features. If possible, we should move to a bitmap implementation which will scale to a
lot more features and also be more time efficient.

bigint is pretty big, isn't it? bitmap would allow for more of course, but how many features will we have?

I second Amit's suggestion. A bitmap is The Right Way to implement it anyway. Plus, to parse the option bigint right now, you have to do quite a lot of CPU-intensive calculations, whereas a regular bitmap would offer you a clean way to store 32 or 64 options right off the bat.

Now that all the code is in CVS with proper tags how about pushing through this change. It should be very simple to move to the bitmap field for feature flag storage: my estimate is that it won't involve more than 2-3 hours of coding/testing.

I am assuming that we have access to the web server machine: the perl cgi code will need to change along with the mailhandler code.

we can change the webserver code as needed. We'd need to "upgrade" the data we have, right?

We can put this off, if we like -- I don't think it's much of an issue currently.

Josh,

We will need the feature map ASAP anyway. Yes, we'll need to change the data. Once we have the mapping of the features as bitmap, we can write a small script that factors the bigints and converts them into the corresponding bitmap.