ye olde sequential ID question

Looking back at this thread, https://groups.google.com/d/topic/event-store/-v09S8iwa4w/discussion, and thinking about how to keep the sequential/numeric IDs my client likes, while using event sourcing. I am left with the same question Michal had at the end. Understanding that streams are great for getting sequential IDs, but how would that work in practice?

Would it be crazy to have a stream for Invoices, where you write all your “Created” events to, and then a projection that creates a new aggregate stream for each InvoiceCreated using the event number from the first write as the Id and linking or copying the created event as the first event in it? Further events on that Aggregate would then write to that stream…

One one hand it feels weird to me, but on the other it kind of aligns with Udi’s whole philosophy of “Don’t create Aggregate Roots” (http://www.udidahan.com/2009/06/29/dont-create-aggregate-roots/ - though this is NHibernate-based so not quite the same).

I’m thinking code could be something like

var invoiceId = Invoices.Create(invoiceData); //writes to “invoices” stream, returns event number

// can now return id to client for future requests/ops

At least in that case I am only writing to one stream. But then it feels weird to “generate” the aggregate stream from that event. The only other approach I can think of is to have a dumb stream that is basically just a sequence generator, and write a dumb event to it, get the number back, and use it for the ID in an InvoiceCreated event, which then is saved to the “invoice-id” stream. But now we are doing two writes instead of one. I’m not super-concerned about gaps in numbers should the second write fail, but it just doesn’t seem like a clean approach.

Any thoughts or is anyone doing anything similar with sequential IDs?

Brian

I’m doing the dumb id stream thing. There’s an id stream for every entity type. The client has to get a new ID before posting. If you try to generate a new ID and save to stream at the same time, you always have the possibility of double posting. If you generate the ID first, you have the possibility of skipping IDs (double-generating). The latter seemed less detrimental to me.

I have a blog post where I explore this topic.

Do you really need sequential IDs or just something capable of k-ordering within a single partition? Have you considered the implications of being able to enumerate the IDs?