How to make id more clear.

[eddieajau]

After fiddling a bit, I've realised that the id property on an Entity is more or less a required property when it comes to integrating it with a Repository. That's not altogether obvious from the outset.

Perhaps it would be worth adding a setId and getId method to Entity. A Repository can then replace entity.id with entity.getId() and now it's using an interface rather than being tightly coupled to a naming convention.

Thoughts?

[mateodelnorte]

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.

[eddieajau]

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.

[eddieajau]

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)?

[mateodelnorte]

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 notifications@github.com
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
.