I'm running this on my macbook pro.

I'm using uuid.Must(uuid.NewV4()).String() to generate random identifiers. I'm generating theses identifiers at a very low rate of a few dozen per days

Here are some non-random UUID that I got in the last weeks:

02524e6f-65a7-4cf5-8000-0000000000002
6e3ef1c8-0000-4000-8000-0000000000001
fa07f1e9-a8a0-427f-8103-e34e000000000
2cfa392b-71d5-4000-8000-000000000000
5f16db16-56ce-4000-8000-000000000000
bac73b37-aab3-498b-8000-000000000000
da5bd82d-4f98-4b51-8000-000000000000
eb245e52-535f-4274-8350-3a7200000000
f7510000-0000-4000-8000-000000000000
5936f955-286e-47ac-8000-000000000000
0a14da92-0000-4000-8000-000000000000
80730000-0000-4000-8000-000000000000
cd2b88a5-0000-4000-8000-000000000000

I think I shouldn't have theses.

To support mapping a struct to db with e.g. https://github.com/jmoiron/modl. But since they are interfaces they are not specific to that implementation.

not enough arguments in call to uuid.Must have (uuid.UUID) want (uuid.UUID, error)

if I install the package using dep dep ensure -add github.com/satori/go.uuid, then Must function expects two arguments.

uuid := uuid.Must(uuid.NewV4(), errors.New("UUID Error"))

but if I install the package using go get github.com/satori/go.uuid, then Must function expects only 1 argument

uuid := uuid.Must(uuid.NewV4())

In both the cases 1.2 version is getting installed

This fixes a case when using the gorm "ORM" with go.uuid on a Postgres database. When a model defines a field as uuid.UUID the introspection that happens will pass in a UUID type.

After this sudden change, everything in my code will NOT work. Not even build with docker

All I get is this multiple-value uuid.NewV4() in single-value context

In certain cases (namely testing) a person may want to deterministically generate UUIDs. There currently aren't many facilities in this UUID library for doing this.

I propose introducing a new interface called Generator. A Generator has all of the standard uuid creation functions on it, but has the advantage of being able to be mocked. Developers wishing to write more testable code can write code that instead of directly using the creation function, instead uses some instance of the Generator interface. For the code they actually want to run, they can inject the Generator returned by the NewGenerator function. When they want to test, they can inject a mocked Generator of their choice (using mockgen, mockery, or their own custom implementation) and deterministically control what UUIDs are generated.

For instance, consider the following generator that might be used for testing. In this case, the author only cares about deterministically generating a certain sequence of V4 UUIDS.

type MyTestGen struct {
  Sequence []satori.UUID
  Iter            int
}

func (_ MyTestGen) NewV1() satori.UUID{return  satori.Nil}
func (_ MyTestGen) NewV2(domain byte) satori.UUID{return  satori.Nil}
func (_ MyTestGen) NewV3(ns UUID, name string) satori.UUID{return  satori.Nil}
func (m MyTestGen) NewV4() satori.UUID{
  toReturn := m.Sequence[m.Iter]
  m.Iter += 1
  return toReturn
}
func (_ MyTestGen) NewV5(ns UUID, name string) satori.UUID{return  satori.Nil}

I need the possibility to have an UUID string without dashes in my project. I didn't want to use strings package to manage it since it could be a new simple functionality.

I feel the tests have an error in them, in that a format is not supported that really, really should be.

While uuid.FromString("6ba7b810-9dad-11d1-80b4-00c04fd430c8") is clearly supported, the string uuid.FromString(""6ba7b8109dad11d180b400c04fd430c8") should also work as well as its considered a valid uuid in many languages and schema frameworks and so this support is important for interoperability... just it does not work at the moment even though it really should, and this has caused us (and I'm sure, many many others) all kinds of issues.

For example, this lack of support for UUID's without dashes makes dealing with marshmallow and Python generated .hex UUID values a big PITA when you trying to use the hex value as a primary key in a DB or massively distributed system.

It also means that while other libraries and languages are generating these "valid UUID's", the UUID framework itself does not support them, so it makes it look like this library doesn't have full support for UUID's.

I understand that some may want to create an overly pedantic discussion about if a UUID without a dash is really a UUID that won't take into account the fact real people are using these libraries to get work done and so this support would make lives easier, but the fact is most people consider them to be valid, many other frameworks consider them to be valid, and so this support really should exist if the core golang philosophy of getting stuff done is to be respected.

I refactor UnmarshalText in order to support yet another text representation of UUID lilke 6ba7b8109dad11d180b400c04fd430c8. The reason is that this format is quite frequent.

I tried to introduce BNF of what UmarshalText actually does. In fact it simplifies implementation and future support. On other hand current implementation led to performance degradation(see below before/after).

BEFORE

BenchmarkFromString-4               	10000000	       122 ns/op
BenchmarkFromStringUrn-4            	10000000	       124 ns/op
BenchmarkFromStringWithBrackets-4   	10000000	       123 ns/op
BenchmarkUnmarshalText-4            	20000000	        81.6 ns/op
PASS
ok  	github.com/daskol/go.uuid	25.786s

AFTER

BenchmarkFromString-4               	20000000	        91.7 ns/op
BenchmarkFromStringUrn-4            	 3000000	       493 ns/op
BenchmarkFromStringWithBrackets-4   	 5000000	       358 ns/op
BenchmarkUnmarshalText-4            	 2000000	       612 ns/op
PASS
ok  	github.com/daskol/go.uuid	27.822s

Eventually correct UnmarshalText should be based on FSA to avoid overhead during parsing.

Hi,

i am having a problem when scanning from MS SQL Server a uuid. The uuid from the app and the value in the db table is the same, but when querying and scan the result i get a different uuid. The same app does work in PostgreSQL just by switching out the driver. Any thoughts?

First of all thanks for a great library.

This is more of a question rather than a real issue: what happens if rand.Read() fails? I realize in practice it probably doesn't fail much (and I've been running a script locally to try and catch a random failure for crypt.Rand() but haven't had any luck) -- but in that rare case what should be the behavior of the library?

Maybe a retry works? If so I'll be happy to do a PR.

https://github.com/satori/go.uuid/issues/73#issuecomment-378573107 the use of ReadFull is now in master but has not been tagged. This is a critical fix for us, can you add a tag as version 1.2.1 (or 1.3). Thanks.

This gofrs has nothing to do with github.com/gofrs. I just want to urge them to support go module asap.

Package main page: https://pkg.go.dev/gitee.com/gofrs/uuid/v4

For Chinese friends suffering from poor network when connecting to GitHub, it's time.

Add COMB (Combined-Time) UUID for V1 and V4.

COMB UUID with ordered-time could optimize insert performance and keep data in ordered state.

https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/

A CVEhas been filed for a 3 year old defect that is fixed on master but has never been tagged and released. With this defect, periodically the UUID V4s will contain mostly 0's.

https://github.com/gofrs/uuid is a maintained fork that addresses this problem and is actively maintained.

https://github.com/satori/go.uuid/issues/73