tryggth / go-uuid Goto Github PK

What steps will reproduce the problem?
1. Create a new UUID
2. Marshal said UUID
3. Unmarshal the result of 2 into a new UUID

What is the expected output? What do you see instead?

Both UUIDs should be equal. Instead, step 3 throws an Unmarshal error. 
Marshaling occurs as is typical for byte slices--it is encoded as a string--but 
Unmarshaling cannot unmarshal a string to type UUID.

What version of the product are you using? On what operating system?

This was confirmed in Go 1.2rc3 on the Go playground: 
http://play.golang.org/p/BUo5pw9BAO. It is running against the latest master of 
go-uuid, 7dda39b2e7d5.

Please provide any additional information below.

This should be simple enough to fix: extend the UUID type to implement 
Marshaler and Unmarshaler. I would expect them to call json.Marshal on 
id.String() (where id is a UUID), and json.Unmarshal, followed by Parse() on 
the result.

If this were on Github or something similar, I'd submit a pull request. 
Unfortunately, I'm unsure as to how to do that on Google Code. Instead, I've 
implemented a variation on the Go Playground: 
http://play.golang.org/p/OXjK4Jdd7w

This could be implemented by aliasing the UUID type locally an extending it, 
but that seems like a silly wrapper to maintain, rather than adding two 
functions to go-uuid.

In GetTime, the clock_seq variable is updated inside a mutex. However, when 
NewUUID accesses the clock_seq, it is outside of this lock. As a result a race 
condition exists where multiple threads will update the clock_seq in an atomic 
fashion, but each of them will generate a UUID with the same value.

I have included a patch file which implements a possible fix.

I have also attached test.go, which illustrates the problem. The following 
results were produced on an 8-core 4Ghz machine with 32gb of ram:

2014/12/01 04:01:04 Creating Channels
2014/12/01 04:01:04 Starting Threads
2014/12/01 04:01:04 Wating for Completion
2014/12/01 04:01:06 Processing Data. Execution took: 2.0741186s
2014/12/01 04:01:13 Found duplicate UUID!!!
2014/12/01 04:01:13 Found duplicate UUID!!!
2014/12/01 04:01:16 Found duplicate UUID!!!
2014/12/01 04:01:17 Found duplicate UUID!!!
2014/12/01 04:01:18 Found duplicate UUID!!!
2014/12/01 04:01:18 Found duplicate UUID!!!
2014/12/01 04:01:19 Found duplicate UUID!!!
2014/12/01 04:01:20 Found duplicate UUID!!!
2014/12/01 04:01:22 Found duplicate UUID!!!
2014/12/01 04:01:23 Found duplicate UUID!!!
2014/12/01 04:01:23 Found duplicate UUID!!!
2014/12/01 04:01:26 Found duplicate UUID!!!
2014/12/01 04:01:26 Done.

The following test is after the patch is applied:

2014/12/01 04:01:44 Creating Channels
2014/12/01 04:01:44 Starting Threads
2014/12/01 04:01:44 Wating for Completion
2014/12/01 04:01:46 Processing Data. Execution took: 2.0071148s
2014/12/01 04:02:06 Done.

UUIDs are often used when working with RDBMSes. It would be convenient if the 
sql.Scanner interface from the database/sql package were implemented.

This is more of a question than a bug, but why not make the UUID a `[16]byte` 
type, instead of the slice, `[]byte`?

Alternatively, to make it backwards-compatible, it could be a pointer type, 
`*[16]byte`.

code.google.com/p/go-uuid/uuid/uuid.go:116: unreachable code
code.google.com/p/go-uuid/uuid/uuid_test.go:319: no formatting directive in 
Errorf call
code.google.com/p/go-uuid/uuid/uuid_test.go:328: no formatting directive in 
Errorf call
code.google.com/p/go-uuid/uuid/uuid_test.go:331: no formatting directive in 
Errorf call


What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.