Change how the database name for cosmos db is generated

[jeremyrickard]

A limitation in the current ARM based CosmosDB provisoning limits the length of the database name to 50 characters, including the name provided, the location name and a dash. In some situations, this means a UUID is invalid. If the length will be too long, this patch will randomly generate a string of the available length instead of using a UUID.

Randomly select characters from a const containing 0-9 and a-z (lowercase).

Fixes #227

[krancour]

Buckle your seatbelt. There's a problem here and it's not easy to explain.

Run this example in the playground a few times and take note of the results:

https://play.golang.org/p/MtB7sGaEPpw

Did you get the same result every time? Was it this?

6fbbd7p95oe8ut5qrttebiwar88s74donnl9x8lipmar2rysjl

The results are deterministic because the default rand.Source (unexported package-level variable named globalRand) in the math/rand package is seeded with the integer 1. Every time a Go program executes with the Source seeded like so, the results of pseudorandom number generation will be completely predictable.

There is a rand.Seed(...) function that permits us to override the default seed of 1 with something sensible like time.Now().UnixNano(). The trouble with this is that we have no guarantee that some other package we use (now or in the future) doesn't stupidly set it back to 1 or 5 or any other hard-coded value that would result in predictable behavior.

So... at this point, the savvy Gopher says, "Ok. I won't user the global rand.Intn(...) convenience function. I'll just instantiate my own seeded Rand like so:"

rnd := rand.New(rand.NewSource(time.Now().UnixNano()))

No one else can tamper with that, so it should be good, right?

No. 😢

As it turns out, the above approach is not concurrency-safe. What's really galling is that the global Rand that we refused to use for other reasons is concurrency safe. So how do they do that? We can just do what they do, right?

Here's the line from the math/rand package where that "global" package-level Rand gets set up:

var globalRand = New(&lockedSource{src: NewSource(1).(Source64)})

So the Source is wrapped in a lockedSource. Cool.

type lockedSource struct {
	lk  sync.Mutex
	src Source64
}

Very nice. But you notice it's not exported. We can't use it.

So-- if we want to be adequately pseudorandom and concurrency-safe, our only option is to create out own concurrency-safe wrapper around a Rand... and that's exactly what's in our own rand package.

See pkg/rand and pkg/generate for some examples uses.

I've opened an issue against Go to highlight how eminently impractical the two out-of-the-box options (global Rand vs non-concurrency-safe Rand) both are.

golang/go#21393

While that issue hasn't been closed, and likely will not be until Go 2, TIL that this new package was created in response to numerous complaints about math/rand. Among the improvements, LockedSource is now exported... but its src attribute isn't, and since there's no exported constructor-like function either, it's still not possible to to wrap a LockedSource around another Source. 😢

Stick with our pkg/rand, I guess.

[krancour]

"truncate" might not be the best word choice for what we're doing.

[krancour]

But the logic and the approach lgtm. Just need to account for the random nonsense.

[jeremyrickard]

That lesson on Go 's math/rand package was a great way to start the day :) I didn't even see our rand package! I'll fix this up to use that. I totally skipped over our generate pkg too. That seems like a more appropriate place for this logic. I'll refactor it a bit and use the stuff in generate 👍

[krancour]

This is where I wish Go had function overloading. Oh well.

[krancour]

This looks spot on. LGTM. Will merge pending CI.