Stream renaming best practice

EventStoreDB
#1

Hi all, I don’t know if it is a thing that I will have to be in the next days or not, but a colleague made me think about it.
At the moment I am creating a Stream per aggregate. I have used the aggregate id for the name of the Stream.

So my system is doing POSTs on “/streams/<AGGREGATE_ID>”.

This aggregate_id is our index per aggregate, so we can follow a “conversation” inside our system for a given aggregate.

A colleague today asked me if there are problems in start doing POSTs on “/streams/<AGGREGATE-TYPE_AGGREGATE-ID>” for some future reasons of clarity about the streamId which will lead us through the “conversation”.

So I am thinking about it (I don’t know if it will become the official solution), but in case it will be, how can I rename streams that I am creating since production release?

I think I should write a projection to link events to (linkTo) the new streams and then deleting the old ones.

Have you ever done that?

#2

It is common to use type-{id} this works with projections as well for from-category.

On a rename you would want to use emit not linkto as with linkto if you delete the original event the linkto will not resolve and will be considered as removed.

Cheers,

Greg

#3

Good point on type-{id}, so probably I will do the rename in the next days.

Thanks for the hint about emit. It will be a “hot stream rename” because the system have to stay online so I am trying to figure out the best way of doing so without screwing up the order of the stream.

An “Advanced Stream management” course is needed. :slight_smile:

Mirko

#4

​Note that you might want to consider formatting Guids without their “-” characters if you want to use fromCategory, though the default as of 3.0.0rc2 is to split on the first “-” rather than the last as was previously the case.

James

#5

Thank you James. My Ids for aggregates are not GUID so there is no problem.
But this is a cool point. As I told to Greg before this evening, a “Stream best practices” guide should be truly awesome. :slight_smile:

Mirko

#6

​Yes that’s not a bad idea. There was a blog post about it a long time ago but we should probably formalise it in the docs.

#7

Are you talking about this: http://geteventstore.com/blog/20130210/the-cost-of-creating-a-stream/index.html ?

If you are interested I can give you some points from an outside point of view. So I have no bias or deep knowledge about Streams and we can write a document for the user which is approaching EventStore.

Mirko