This is a roundup of a discussion that has been taken place in Ticket
1180 about guid generation. http://code.djangoproject.com/ticket/1180
I put it here because discussion should take place in the list. (sorry
hugo for putting my suggestion in the ticket, it was my lazy sunday...)
- The mechani
>session_key = md5.new(GUID.generate() + SECRET_KEY).hexdigest()
>Benefit: unique session key without the need to access the database,
>really fast (more than 20.000 session key per second)
>Drawback: Additional third party dependency.
It's not faster than the current version - it does the same
> Actually the GUID.generate() is more complex than the current version.
True. The fun thing about the recipe is that it produces keys that are
so unique that they do not need to be checked against a db. That's
where the performance benefit comes from. And I think not checking
against a db is the
>True. The fun thing about the recipe is that it produces keys that are
>so unique that they do not need to be checked against a db. That's
>where the performance benefit comes from. And I think not checking
>against a db is the "other context" mentioned in the ticket.
Actually it doesn't. It dep
> Just a simple cronjob with an SQL statement that blows away outdatedsessions.Any thoughts of putting this into the bin or maintenance subdir of Django distro?Radek
On 1/9/06, hugo <[EMAIL PROTECTED]> wrote:
>True. The fun thing about the recipe is that it produces keys that are>so unique that the
>Any thoughts of putting this into the bin or maintenance subdir of Django
>distro?
There is one in the bin directory, only that script has an additional
dependency on the user registrations and so won't run right away,
because only ellington users will have that table.
bye, Georg
