SequentialGuid AsString not sequential when generating Guids in for loop.

[borisdj]

When I generate several Guids, with SequentialAsString type, in a 'for' loop

        for (int i = 0; i < 20; i++)
        System.Console.WriteLine(SeqGuid.NewGuid(SequentialGuidType.SequentialAsString));

it gives the following guids:

39c27317-3f03-3ed1-2a27-d0e4b21bc541
39c27317-3f04-c80a-a605-59a55e951bfa
39c27317-3f04-b3dd-8464-7d229af028bc
39c27317-3f04-8fe5-fe83-dbcfe4067dc1
39c27317-3f04-6f10-84dd-75d5d0e89aa7

As you can see third and fourth Guid does not look sequential ?
I am using this for PostgreSql.
Now from what I understand first 2 block shold be sequential but here they are the same.
Obviously generator is using some time value and this is created in milliseconds that it gives the same result.
So is this a valid SeqGuid, if not can it be fixed ?
One way I could fix it is using some sleep method in loop, what do you think?

[jhtodd]

Heya,

Since the sequential portion of the GUID is based on a timestamp with
limited resolution, when you generate several GUIDs within a tight loop
like that, it's possible that they'll all have the same timestamp. You
might think that would affect insert performance, but in my tests it really
didn't make a difference. You could adjust the resolution of the timestamp
if you want finer control (although in Windows the minimum resolution is
10ms), or you could perform a small delay between each generation (e.g.
Thread.Sleep(10) or something), but in the real world it probably wouldn't
make a noticeable difference unless you're generating thousands of GUIDs
all at once.

Jeremy

On Mon, Nov 4, 2013 at 8:46 AM, borisdj notifications@github.com wrote:

When I generate several Guids, with SequentialAsString type, in a 'for'
loop

    for (int i = 0; i < 20; i++)
    System.Console.WriteLine(SeqGuid.NewGuid(SequentialGuidType.SequentialAsString));

---

it gives the following guids:

39c27317-3f03-3ed1-2a27-d0e4b21bc541
39c27317-3f04-c80a-a605-59a55e951bfa
39c27317-3f04-b3dd-8464-7d229af028bc
39c27317-3f04-8fe5-fe83-dbcfe4067dc1
39c27317-3f04-6f10-84dd-75d5d0e89aa7

As you can see third and fourth Guid does no look sequential ?
I am using this for PostgreSql.
Now from what I understand first 2 block shold be sequential but here they
are the same.
Obviu

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1
.

[borisdj]

Thanks for prompt reply.
I thought it was situation as you explained, but just wanted to check.
I have some list of data for import so I loop through it, generate ID and insert it.
So far none of the list is more then 1000, but I would like to make it so it does not depend on size.
I will first try to fix it by changing resolution. Sleep period would be second option since it will add some delay from the performance aspect.

[jhtodd]

If you're generating the ID and inserting the record all within the same
loop, I think this probably won't be an issue at all -- the delay from the
database insert should be enough to keep the repeated timestamps to a
minimum (unless your database is a lot faster than mine! :). It's mostly
situations like your example code where a loop is doing nothing but
generating a whole lot of GUIDs at once where it can become an issue -- and
even then, probably not a huge one.

Jeremy

On Mon, Nov 4, 2013 at 10:44 AM, borisdj notifications@github.com wrote:

Thanks for prompt reply.
I thought it was situation as you explained, but just wanted to check.
I have some list of data for import so I loop through it, generate ID and
insert it.
So far none of the list is more then 1000, but I would like to make it so
it does not depend on size.
I will first try to fix it by changing resolution. Sleep period would be
second option since it will add some delay from the performance aspect.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-27700492
.

[borisdj]

I am actually inserting records, not one by one, but by chunks of 100, precisely in order to speed up insert.
So Guid generation .NewGuid(... is called for these 100 records in memory in a very short time, and only after this SaveChanes() is called.
I have tested this on real project and I do get records with Guids that have same first 2 blocks.

What is interesting is that third block still make it sequential.
Shouldn't third one be random, so is this coincidence or ?

This is part of Guid list:

39c5365e-a8ab-006e-b5a3-19b4abb4f7b0
39c5365e-a8b2-4531-d2c7-2704a81fbc44
39c5365e-a8b2-54ba-0417-73122800d5f6
39c5365e-a8b2-8920-d0cd-8f1c1b8eafd7
39c5365e-a8b2-ab2b-3bb3-726b80cc49db
39c5365e-a8b2-cd0b-e8be-c11ddd44160d
39c5365e-a8b2-d324-8976-00f94e5493a3
39c5365e-a8b2-d46d-9e71-90e79380b4b9
39c5365e-a8b2-d814-08de-e94f01bed5dd
39c5365e-a8b2-df2a-7c76-08f3633f5657
39c5365e-a8b2-f668-157a-91ee3a92555a
39c5365e-a8b3-19e3-9d46-5d8d7277ebab
39c5365e-a8b3-305e-60d1-3c991c953291
39c5365e-a8b3-53e2-5dae-b7a5d78b63bf
39c5365e-a8b3-5ca2-6767-b748f7a25da4
39c5365e-a8b3-7051-7e35-1486ab805377
39c5365e-a8b3-7e9c-9172-7aa31b06ad59
39c5365e-a8b3-89c9-3e8b-19844502cab7
39c5365e-a8b3-9629-08ff-44bd87703b8f
39c5365e-a8b3-9631-9296-e6120e27da50
39c5365e-a8b3-96fd-00c0-89a4d927a7e4
39c5365e-a8b3-c77c-624a-6cf15f02e616
39c5365e-a8b3-e874-455d-ca44afb208c6
39c5365e-a8b4-8388-5570-9b9fcc6052d3
39c5365e-a8b4-92af-6296-ad7a20606a64
39c5365e-a8b4-ac7f-9199-403d0ff1c227
39c5365e-a8b4-b623-b3f3-4c3c1b63e70d
39c5365e-a8b4-c477-612b-c1028cd6e7cb
39c5365e-a8b4-f41a-4560-012a32882e02
39c5365e-a8b5-025f-281f-7b851a76a6c4

[jhtodd]

Yes, that third block is very interesting! Can you tell me offhand what
version of Windows you're running this on?

Did you make any changes to my code? I don't see how the version on Github
could be touching that third block, and I also can't imagine that
RNGCryptoServiceProvider would provide sequential values like that.

Also, the sample GUIDs you listed in your first e-mail didn't have
sequential third blocks like these...were those real values, or did you
just make them up as examples?

Jeremy

On Mon, Nov 4, 2013 at 12:25 PM, borisdj notifications@github.com wrote:

I am actually inserting records, not one by one, but by chunks of 100,
precisely in order to speed up insert.
So Guid generation .NewGuid(... is called for these 100 records in very
short time.
I have tested this on real project and I do get records with Guids that
have same first 2 blocks.

What is interesting is that third block still make it sequential.
Shouldn't third one be random, so is this coincidence or ?

This is part of Guid list:

39c5365e-a8ab-006e-b5a3-19b4abb4f7b0
39c5365e-a8b2-4531-d2c7-2704a81fbc44
39c5365e-a8b2-54ba-0417-73122800d5f6
39c5365e-a8b2-8920-d0cd-8f1c1b8eafd7
39c5365e-a8b2-ab2b-3bb3-726b80cc49db
39c5365e-a8b2-cd0b-e8be-c11ddd44160d
39c5365e-a8b2-d324-8976-00f94e5493a3
39c5365e-a8b2-d46d-9e71-90e79380b4b9
39c5365e-a8b2-d814-08de-e94f01bed5dd
39c5365e-a8b2-df2a-7c76-08f3633f5657
39c5365e-a8b2-f668-157a-91ee3a92555a
39c5365e-a8b3-19e3-9d46-5d8d7277ebab
39c5365e-a8b3-305e-60d1-3c991c953291
39c5365e-a8b3-53e2-5dae-b7a5d78b63bf
39c5365e-a8b3-5ca2-6767-b748f7a25da4
39c5365e-a8b3-7051-7e35-1486ab805377
39c5365e-a8b3-7e9c-9172-7aa31b06ad59
39c5365e-a8b3-89c9-3e8b-19844502cab7
39c5365e-a8b3-9629-08ff-44bd87703b8f
39c5365e-a8b3-9631-9296-e6120e27da50
39c5365e-a8b3-96fd-00c0-89a4d927a7e4
39c5365e-a8b3-c77c-624a-6cf15f02e616
39c5365e-a8b3-e874-455d-ca44afb208c6
39c5365e-a8b4-8388-5570-9b9fcc6052d3
39c5365e-a8b4-92af-6296-ad7a20606a64
39c5365e-a8b4-ac7f-9199-403d0ff1c227
39c5365e-a8b4-b623-b3f3-4c3c1b63e70d
39c5365e-a8b4-c477-612b-c1028cd6e7cb
39c5365e-a8b4-f41a-4560-012a32882e02
39c5365e-a8b5-025f-281f-7b851a76a6c4

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-27709339
.

[borisdj]

Sample Guids from first comment are made in simple console app.
I am using Windows 8.
But in .Net project (and I didn't make any changes to your code) I got Guids that seems sequential !?
I will check and test this more.
(I am using VS 2012 with it's IIS Development Server)

[jhtodd]

Yeah, I'll take a look too when I get home. That's a very interesting
effect!

On Mon, Nov 4, 2013 at 12:53 PM, borisdj notifications@github.com wrote:

Sample Guids from first comment are made in simple console app.
I am using Windows 8.
But in .Net project (and I didn't make any changes to your code) I got
Guids that seems sequential !?
I will check and test this more.
(I am using VS 2012 with it's IIS Development Server)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-27711689
.

[borisdj]

After additional testing and inserting another list of records I got the following order in database:
39c536e5-c0be-e706-ea9a-972e28b295db | num1
39c536e5-c0c7-4ea6-29b2-304d723f3ae2 .| num2
39c536e5-c0c8-4ef7-1cc0-689820b09ebf ..| num3
39c536e5-c0c8-523b-4775-c4ea1ff63c3e ..| num4
39c536e5-c0c8-ffb4-4833-590f2c50e308 ...| num5
39c536e5-c0c9-3257-2bd3-65774cb37303 | num7
39c536e5-c0c9-c0ec-3dd0-e0a5b79ffbe6 ..| num6
39c536e5-c0ca-673e-4f28-e597abd91b94 .| num10
39c536e5-c0ca-ba9d-0810-c8cfd4471fb2 ..| num8
39c536e5-c0ca-e893-b616-0aa866d2f1e0 .| num9

I think I understand what is happening.
The list in memory was in order num1-10 and Guids were not sequential, as expected.
But when I sent all these record to Database with SaveChanges() they were inserted in Db with sequential Guid order, changing the initial order of list in memory.
As ORM I am using EF 5. So it is EF fault, or shall I say merit.

But I still think that this should be made in the way that it always return sequential Guid.
Like it is done here:
http://www.siepman.nl/blog/post/2013/10/28/ID-Sequential-Guid-COMB-Vs-Int-Identity-using-Entity-Framework.aspx
Now this is only for MsSQL since type is SequentialAtEnd but it should be easy to move this sequence at the begining.