So how can/should we get a count?
That's because of the HiLo algorithm Ayende mentioned.
Hi Itamar.
I really really really appreciate that you've spent some on your time
having a look at my newbie question. Sincere regards!
Comments inline
Correct .. but isn't this the correct way to do it? To me, this is the
>>every time you run the test you create a new document store.
same analogy as if I restart the AppPool of my IIS website. So would
this mean that if I have a website, and I add 10 documents to the
collection when it first 'started up', the Id's would be 1-10. Then,
if the app-pool is restarted for that website, then the next document
to be added will have an id of .. i donno .. something else BUT most
likely not 11?
> When creating a new DocumentStore object which connects to a remote RavenDBHmm. hold on. I really don't understand something now, A DocumentStore
> server, new HiLo keys are generated and exchanged.
<-- isn't that the database i'm connecting to inside RavenDb.
Because i'm still stuck in RDBMS world, the poor analogy here would
be :-
* SqlServer / RavenDb == The Service/Servers.
* AdventureWorks / Default Database == the databases.
Hmm. so how would an database stay sequential? The service/console is
> In your application, as long as you don't close the docstore object, you're
> safe.
still running, but the unit test or more importantly, the web site
(app-pool) is constantly starting / stopping.
Now, what I still felt was missing was any mention about document
identity ~generation~.
I always assumed that
the type AND the id defines a document as unique. Which is why you
don't have multiple Id's of '1' or '2', etc.. Espeically how thinsg
are visualized into collections. Dangerous trap, that (for us first
timers). Ok. kewl!
But there is nothing about how these id's are autogenerated. There are
some conventions that take place (and can be manually defined) in
another page (connecting-to-a-ravendb-datastore.markdown). But no
mention about how they are created and what we must care about.
In the G-Group forum here, people method the HiLo algorithm .. sure ..
but do I need to care about this? Should I just want to know that the
id's will just be sequential? Earlier on, you said "When
creating a new DocumentStore object which connects to a remote RavenDBserver, new HiLo keys are generated and exchanged.". To me (remember:
i'm still trying to get my head around this), a DocumentStore object
is an expensive ~application-wide~ object. Gotcha. It's not the DB,
but the client-side object that will communicate with it.
"DocumentStore is what enables you to connect to it from a clientapplication". So why is this Store in charge (to some degree) with
generating these HiLo keys? That's what i don't get. Why can't it just
ask the DB for these keys so it can continue sequentially making
numbers.
If my website app-pool recycles, then now my numbers will be
different, right? A new Application_OnStart is fired .. a new
DocumentStore instance is created .. and therefore new HiLo's are
generated.
Maybe the real question is: do I really care for incremental numbers?
That's sooo 1970's with RDBMS's... ?? I feel it's important but i'm
just new to this noSql thing.