[erlang-questions] Use of uuidgen with a mnesia application

Alexander Lamb <>
Fri Jun 6 17:06:40 CEST 2008

I see, but it means you wrote a piece of code in C (probably) to call  
uuid on the underlying system?

(maybe it's the word "drive" that I didn't fully understand.


Le 6 juin 08 à 16:58, Paul Fisher a écrit :

> On Fri, 2008-06-06 at 16:43 +0200, Alexander Lamb wrote:
>> make_guuid() ->
>> 	First = os:cmd("uuidgen -t"),
>> 	case verify_guuid(First) of
>> 		true	-> Result = First;
>> 		false	-> Second = os:cmd("uuidgen"),
>> 				   case verify_guuid(Second) of
>> 						true  -> Result = Second;
>> 						false -> Result = "error",
>> 								 throw({uuidgen_error,Second})
>> 				   end
>> 	end,
>> 	erlang:list_to_binary(Result).
>> Now, the reason I have this cascade of case is because on Linux (our
>> Ubuntu servers) it recognizes the -t option to generate the uuid and
>> on MacOSX (our dev machines) it does not.
>> Call me crazy, but I never feel confortable about using a totally
>> random uuid to identity medical records that might be copied from
>> system to system, exported, etc... even if the probability of
>> collision is lower than that of a large asteroid hitting earth!
>> What is your strategy for this (maybe this is a question to ask the
>> couchdb developers, since they use guuids to identify the documents)?
> We use uuid values to manage jobs on our cluster processing
> infrastructure and have a very simple driver that calls the uuid  
> library
> directly and sends the tuple back to the caller (e.g. {uuid,
> <<156,21,52,30,51,213,17,221,179,34,0,28,37,116,215,248>>}).  The
> os:cmd() trick is just a quick and dirty solution because of the
> differences in systems.
> Short of keeping track of unique ids in a database read/write from all
> cooperating systems (and potentially introducing a bottleneck or point
> of failure in the processes), uuid values are the best approach.
> -- 
> paul

More information about the erlang-questions mailing list