I think it's highly unlikely that you'll have a key collision given that most webapps can expect at most a few thousand sessions and 8.39299e+17 is a very big number :)
In production code, though, I would make this code more efficient: length(lists:seq($a, $z) ++ lists:seq($A, $Z) ++ lists:seq($0, $9)). It should lookup each element from a fixed size tuple. On Thu, Feb 21, 2008 at 4:23 AM, jm <[EMAIL PROTECTED]> wrote: > > > > length(lists:seq($a, $z) ++ lists:seq($A, $Z) ++ lists:seq($0, $9)). > 62 > > > math:pow(62,10). > 8.39299e+17 > > Mmm, very little chance of collision in the original algorithm. > > > gen_key() -> > F = fun() -> > choose_key(5) > end, > mensia:transaction(F) > > choose_key(0) -> > %% time to panic > undefined; > choose_key(Count) when is_integer(Count) -> > Chars = lists:seq($a, $z) ++ lists:seq($A, $Z) ++ lists:seq($0, $9), > Key = [lists:nth(crypto:rand_uniform(1, length(Chars)), Chars) || > N <- lists:seq(1, 10)], > case mnesia:read(cont, Key, read) of > [] -> > %% choose again > choose_key(Count - 1); > [_ContRec] -> > Key > end. > > Just thinking about edge cases and what would be the correct course of > action when a key collision occurs. > > Jeff. > > > jm wrote: > > Yariv Sadan wrote: > > > >> Yeah, it looks similar in the way it uses processes for user sessions. > >> Unfortunately, the documentation doesn't say much about how to use it > >> to build full apps. > > > > I know your code is really only a proof of concept, but I noticed that > > your gen_key() function doesn't test for key collisions. The code I've > > been testing is a little more complicated. It walks the mnesia table to > > find the max id and adds one then encodes to/from a modified base64. The > > modification to base64 is to replace $+ with $- and $/ with $_. > > Encryption/decryption of the integer id is added to avoid making the ids > > guessable, but this is frankly all a little heavy handed. > > > > I wont post all the code as there's about three or four versions/ways of > > doing things in the same file and not all of it works at the moment as I > > keep changing my mind on how to approach problems. Anyway, use anything > > that's proves useful. > > > > Really it comes down to how likely a key/id collision is and how to > > guarrantee that a unique key can be generated in near O(1) time for a > > large number of sessions. > > > > > > Jeff. > > ------------- > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "erlyweb" 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/erlyweb?hl=en -~----------~----~----~----~------~----~------~--~---
