How to I specify identity type attribute during insert query in C# driver?

[Projapati]

All of my ids are numeric id (identity column in sql table). During
insertion it will be incremented by one.
How do I specify the value of this column's value?

Worst case: read the last value from by find and add one to it.

Thanks

[Scott Hernandez]

You can either create a counter document using findAndModify (to
increment and return the next id atomically) or you can keep a counter
on the client (which can be challenging with multiple clients).

Have you considered using a type that doesn't these restrictions? If
no, you might want to think about it.

> --
> You received this message because you are subscribed to the Google Groups "mongodb-user" group.
> To post to this group, send email to mongod...@googlegroups.com.
> To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.
>
>

[Projapati]

"Type that doesn't have this restriction" what did you mean? You meant
GUID which doesn't need increment?
All of my ids are numeric.

On counter document:
If I have 10 collection each having the auto increment attribute, then
I would 10 counter documents. Right?

Auto generated ids are too big. I didn't use GUIDs in sql as well.

[Scott Hernandez]

On Sun, Apr 10, 2011 at 7:15 PM, Projapati <mohamm...@gmail.com> wrote:
> "Type that doesn't have this restriction" what did you mean? You meant
> GUID which doesn't need increment?

Like the default ObjectId, yes.

> All of my ids are numeric.

Just because your existing ids are numbers doesn't mean your new ones
must be. Each document can its own type since there is no restricting
schema.

> On counter document:
> If I have 10 collection each having the auto increment attribute, then
> I would 10 counter documents. Right?

Yes.

However, a system like this is inherently problematic if there is high
contention for those counters. It may delay/block insertion of new
data when you need to increment it. If you have a low write volume
this may not be a problem, but you should be aware of these
considerations as they may affect you in the future.

[Projapati]

I agree the id doesn't have to auto increment type. But that was so
easy choice in SQL.

On the write volume:
The site will be public media sharing site (youtube\flickr type).
Given that the reads will larger than write.

Does scalability and sharding will be impacted by my choice?
Is there a documentation/discussion on this topic that I can go
through?

Thanks

On Apr 10, 7:20 pm, Scott Hernandez <scotthernan...@gmail.com> wrote:

[Scott Hernandez]

On Sun, Apr 10, 2011 at 7:36 PM, Projapati <mohamm...@gmail.com> wrote:
> I agree the id doesn't have to auto increment type. But that was so
> easy choice in SQL.
>
> On the write volume:
> The site will be public media sharing site (youtube\flickr type).
> Given that the reads will larger than write.
>
> Does scalability and sharding will be impacted by my choice?
> Is there a documentation/discussion on this topic that I can go
> through?

Yes, you should (re)search the archives from the list and read up on
sharding if you plan to do this. It is best to put a plan together
before you need to shard if scalability is a concern.

[Projapati]

Auto sharding is one of the main factors choosing MongoDB.
GUIDs will occupy more space than numeric ids(one drawback)

Which will be less painful choice for a system that utilize sharding -
GUIDs or Numeric ids?

[Robert Stam]

The choice of what data type to use as your _id value is mostly
unrelated to sharding. A good discussion of what field(s) to use as
your sharding key can be found at:

http://www.mongodb.org/display/DOCS/Choosing+a+Shard+Key

While numeric ids will save you a few bytes, the headache of
allocating unique values efficiently is significant (as is the
performance overhead).

An ObjectId is 12 bytes rather than 16 bytes for GUID, so normally
people use ObjectId instead of GUID.

[Projapati]

I will sacrifice few extra bytes and going with object ids instead of
long ids.
I just can't do anything that has slow performance and impacts
sharding.

I found these other comments from from my google search.
--------------
Eliot Horowitz added a comment - Jul 29 2009 08:04:05 AM UTC
the problem with auto increment ids is that it doesn't work in a
sharded environment. you would have to synchronize across machines,
which would make it very slow.

why do you need this rather that a guid (like ObjectId)?
--------------
Eliot Horowitz added a comment - Jul 29 2009 09:18:50 PM UTC
so, my general feelings:
- int auto increment is to small these days
- long is 8 bytes
- ObjectId is 12, so not too much bigger
- with ObjectId you can get sharding, which is more beneficial

What are your thoughts on these?
---------------