Storing Commands

[Paul Bowman]

Hello,

A simple question is it sensible to store commands in the EventStore as well Events?

Why do I ask? There seems to be an opinion that one should also store Commands as well events for completeness if nothing else.  Then again do I need to store commands? I have done in the past is there any tangible benefit in doing so?

Thanks.

Paul

[James Nugent]

Hi Paul,

There's no reason you can't store commands either in their own streams or as metadata on the events they are responsible for producing. Although things are named events, we don't actually care what is inside (the client API for example just takes byte arrays for both metadata and data).

There *can* be benefits to keeping hold of commands - regression testing or audit, for example.

Cheers,

James

--
You received this message because you are subscribed to the Google Groups "Event Store" group.
To unsubscribe from this group and stop receiving emails from it, send an email to event-store...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Paul Bowman]

James, OK thanks for the quick response.

[Gabriel Schenker]

we store all our commands in a separate stream. Storing commands can be useful if you want to find out what ultimately triggered events (trouble shooting or so)

--

[James Nugent]

If you do that it's probably worth storing the ID of the command as a correlation ID on the events produced by it.

On 13 Aug 2013, at 16:14, Gabriel Schenker <gnsch...@gmail.com>

 wrote:

[Szymon Pobiega]

I experimented with not only storing but also sending commands via EventStore i.e. a dedicated stream would serve as a command queue. In my experiment there was one command stream/queue per command handler/autonomous component/how do you call it

2013/8/13 James Nugent <ja...@geteventstore.com>

[Paul Bowman]

Interesting how did that work out?

[Szymon Pobiega]

It was only an experiment. I never did anything production on it but it seem to be able to handle ~300 tx/s on my laptop (tx being send command, receive command, generate event, denormalize to ravenDB)

2013/8/14 Paul Bowman <paul.bow...@gmail.com>

[Gabriel Schenker]

Yeah, we do that.

[James Nugent]

Bear in mind that an event store is inherently a queue as well - there's no reason that if you need command queueing you couldn't do that in an event stream.

Cheers,

James

[Rinat Abdullin]

James, in that case, how would you use ES capabilities to implement competing consumers?

Best,

Rinat

[James Nugent]

To do competing consumers you probably want something else sitting on top maintaining the position of the current head, there isn't a nice way to do it using just the event store.

Cheers,

James

On 15 Aug 2013, at 12:01, Rinat Abdullin <rinat.a...@gmail.com>

 wrote: