On Thu, Feb 10, 2011 at 7:36 PM, Tom Evans <[email protected]> wrote: > On Thu, Feb 10, 2011 at 6:56 AM, Russell Keith-Magee > <[email protected]> wrote: >> However, my concern here is that for any value of N, there will be >> some level of traffic that will render that N insufficient. I'm not >> fundamentally convinced that allowing N to be configurable will >> actually fix the problem. I'd be much more interested in seeing a >> genuine attempt to fix the problem, rather than just paper over it a >> little more. >> >> Of course, I haven't given any thought to what that fix would look like... >> >> Yours, >> Russ Magee %-) >> > > Hi Russ > > The main problem is that collisions in md5 are inevitable given enough > users. Would it be possible to consider changing the session key > generation for a uuid based solution? UUID4 in its standard format is > 36 characters, and* if you were to generate 100 billion keys a second > for the next 100 years, the chance of creating one duplicate in all of > those would be ~50%. > > uuid is not part of python 2.4, so we would have to add an > implementation to django.utils.hashcompat. > > If this sounds amenable, I can code up a patch for the ticket.
The DB model for cache keys provides for 40 characters, so we can certainly store a UUID. If you can provide an implementation and can demonstrate that it won't be prone to key collisions and won't impose any computational limits (e.g., it's easy to avoid collisions if you have a global synchronization lock allocating ids), then it's probably worth looking at. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
