Question about identity creation with different session types.

[Justin A]

Hi,

I have a simple unit test where i'm saving a document, then checking to see what the Id is (what was just generated). In this test, the Id's are -not- consecutive, when I thought they should be?

Here's the code with explanations.

// DocumentStore is an Embedded in memory ds. This is all in a unit test.

// First, insert 20 documents into the document store. 

// Insert is using OpenSession (ie. -syncronous- code).

<snipped - pretty simple code>

// Id's are accounts/1, accounts/2 .... accounts/20.

// -- SO FAR SO GOOD --

// Now, lets add a document

// Act.

using (var a = DocumentStore.OpenSession())

{

    a.Store(account);

    a.SaveChanges();

}

// Id is accounts/21. Again, so far so good..

var sd = FakeData.FakeAccounts.CreateAFakeAccount();

using (var b = DocumentStore.OpenAsyncSession())

{

    await b.StoreAsync(sd);

    await b.SaveChangesAsync();

}

// Ru_roh - sd.Id is accounts/33.

It's like .. there's something weird going on between sync and async.

I've always thought that the DocumentStore (for this instance) has the identity-batch .. but when i went to async mode, it .. asked for another batch?

So the id's are related to both the session _type_ (eg. sync or async) and the doc store?

For shits and giggles, i switched the saves around. create 20 sync, then async save, then sync save. Same thing occurs. 

Ids are

accounts/1 -> accounts/20

sd.Id == accounts/33

then

a.Id == accounts/21

So it's not the order it was happening in, but the session type.

Is this the expected behavior? and why?

[Justin A]

I've created a full repo of this problem here using RavenDb.Tests.Helpers.

[Oren Eini (Ayende Rahien)]

Try it out with two calls on async & sync, and it will probably become clearer.

They are both generating _independent_ sequential numbers.

So sync is generating a/1,a/2, a/3

And async is generate a/33,a/34,a/35, etc.

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Justin A]

Yep, I tried that too but I think I failed to clarify my question :blush:

I thought that the Id's which the document store creates have no direct relation to the document session types. I thought the document store has an allocated batch of id's and when that batch is exhausted, it then requests the next batch from the database.

So, if i have a document store that has been allocated the following id's. = a/1 <-> a/32 ... then if i use an OpenSession (sync) or OpenAsyncSession (async) .. i'll still get the next avail identity in that batch.

What it looks like. is that the identity is now a based upon the document store instance _and_ the session type.

To clarify, I was expecting this.

Document Store #1. It has an identity batch of a/1 <-> a/32.

OpenSession() #1 -> a/1

OpenSession() #2 -> a/2

OpenAsyncSession() #1 -> a/3  (not a/33)

OpenAsyncSession() #2 -> a/4 (not a/34)

openSession() #3 -> a/5

.. etc.

[Oren Eini (Ayende Rahien)]

Justin,

You are correct in principle, but the hilo generator is duplicated, one for async and one for sync.

Because of that, we have different ids for sync & async.

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

[Justin A]

:~( Oh noes, that hurts :( I know we shouldn't be emotionally attached to sequential numbering, though :(

Too hard for there to be 1 hilo generator?

[Justin A]

Also - am I the only one that didn't know this? It feels like it's a pretty important and fundamental concept ... which i've never read before?

[Oren Eini (Ayende Rahien)]

We have two because they are actually different impl for each. And they behave differently.

We _could_ merge them, but that would be pretty hard to do

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

--

[Oren Eini (Ayende Rahien)]

Why do you care about ids?

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

On Sat, Jan 31, 2015 at 2:09 PM, Justin A <jus...@adler.com.au> wrote:

Also - am I the only one that didn't know this? It feels like it's a pretty important and fundamental concept ... which i've never read before?

--

[Justin A]

Why do you care about ids?

I'm guessing it's an irrational, emotional thingy (that's the medical term :P) for a simple concept to be applied inside a complex system.

Do i need it to be sequential else the world will break? definitely not. There's no technical basis, etc. Just some weird emotional thing in my head.

It's weird - i can deal with breaking sequential's between doc stores or a doc store restart .. but it really threw me today when I had some code that was mixing sync with async and noticed the id's were different. I thought to myself: I just groked the HiLo concept for the 1000000 time recently (including updating the RavenDb docs) and then this happened :P

Well - I got the answer then :)

(time to update the docs again :P )

[Kijana Woodard]

No. You are not the only one who didn't realize that.

I would say it violates the principle of least surprise.

That said, I don't really care.

I would have thought though, without reading the code, that now that sync api delegates to async code [in 3.0] that such a split wouldn't exist.

--

[Justin A]

> I would have thought though, without reading the code, that now that sync api delegates to async code [in 3.0] that such a split wouldn't exist.

Yep @Kijana! That's what i was thinking, when I was reading Oren's reply also. I thought (in 3.0) that the sync is just calling async with .. .Result :P

[Oren Eini (Ayende Rahien)]

The low level API does so, yes, but higher level stuff ( like hilo ) wasn't changed, so we still have 2 impl.

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

On Sun, Feb 1, 2015 at 12:50 PM, Justin A <jus...@adler.com.au> wrote:

> I would have thought though, without reading the code, that now that sync api delegates to async code [in 3.0] that such a split wouldn't exist.

Yep @Kijana! That's what i was thinking, when I was reading Oren's reply also. I thought (in 3.0) that the sync is just calling async with .. .Result :P