How to make `id` more clear. about sourced HOT 4 CLOSED

Nothing in sourced causes a requirement to have an id property. sourced-repo-mongo does make special use of that property, but you could also provide some different index property. And another sourced-repo-cowbell could do things differently.

If I were to make a dev-centric constraint, it would be in the .commit function of sourced-repo-mongo to throw or return an error if attempting to commit an entity that does not have an id.

from sourced.

And another sourced-repo-cowbell could do things differently.

I think it would be problematic if sourced-repo-cowbell decided it needed your entities to include a pk field (or whatever) while sourced-repo-mongo requires id. It seems to me that the entity has the right to own what it's primary key is, and then a repository can just use the value for that key. If you don't do that, then it presents an interoperability problem and you have to change your entity depending on what repository you are using.

from sourced.

Just out of interest though, what do you use to handle an auto-increment sequence for id's (in the context that I'm coming from an experience where the SQL based ORM just did it for you)?

from sourced.

It's up to you to implement your id scheme. There a lots of modules that
can help do this.

You can't just let a database give you a new entity id, because that column
(or property with some sort of index on it, in a document db) is not going
to be unique. There will be many events of a single id. So autoincrement
won't work.

In general, though, if you search around you'll find lots of arguments
against using auto-incrementing ids.

If I'm creating entities that won't likely need to be sharded in any
particular way, I usually use the https://www.npmjs.com/package/uuid .v4()
method, but there are plenty more such as meteor's implementation:
https://github.com/eface2face/meteor-mongo-id.

If my data will be sharded alphabetically, numerically, by location, etc,
I'll typically create a function that generates a new unique id that
contains that information, and possibly also a portion of a uniqueId().
That way your services can load up and grab their appropriate data, for
caching purposes, etc.

On Thu, Sep 15, 2016 at 6:43 PM, Andrew Eddie [email protected]
wrote:

Just out of interest though, what do you use to handle an auto-increment
sequence for id's (in the context that I'm coming from an experience where
the SQL based ORM just did it for you)?

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#23 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAh3X36w8b3p30GsnKWo79MrzOE32mm2ks5qqcn3gaJpZM4J9h7n
.

from sourced.