search

GreanTech / AtomEventStore

A server-less .NET Event Store based on the Atom syndication format
MIT License
117 stars 14 forks source link

Possibility of using custom URNs #109

Closed AlexSugak closed 8 years ago

AlexSugak commented 8 years ago

Hello!

I am currently working on a project where I would like to have an event stream per "subject" (or "topic") which is identified by its unique name. The topic itself doesn't have any additional information except its events. So, naturally, I would like to have this name as an Id of the event stream.

If forced to use uuid IRIs I will have to add additional storage for storing topic name-uuid mappings. Which means additional step for creating new "topic" as well as additional lookup (to read topic's uuid) when reading events. So I was thinking maybe I could use custom URNs, e.g. urn:x-mycustomnid:topicname

Do you think this is a valid use case? Is it a good idea to have AtomEventStore support custom URNs?

ploeh commented 8 years ago

When building applications with AtomEventStore, I've occasionally encountered the same scenario, so I've been considering this question as well.

When that has happened, I've also had to persist some sort of mapping between public IDs and implementation IDs. You can put such a mapping in a well-known event stream as well, or simply in a flat file. Once a public ID is assigned an internal ID, that pair never changes (I hope), so you can often keep such a map in memory. Thus, it may not be terribly inefficient to have to do a lookup.

So far, I've come to the conclusion that it may be a benefit that you can't use custom URNs as IDs. If you want to use a custom ID schema, doesn't it imply that you have a 'natural' ID in the domain?

It ought to be well-known that one should never use information-carrying IDs (as, e.g. ISBNs) as implementation IDs, but in my experience, that rule of thumb extends to any sort of externally defined ID. Externally defined IDs change. The schemas change (as happened with ISBNs). The generator of the externally defined IDs undergoes a change in platform. Companies issuing IDs merge with other companies, and change schemas in order to avoid collisions.

I can't think of a single code base I've ever worked on where I didn't regret if we used externally defined IDs internally. Conversely, I can't remember a single code base where I've regretted decoupling externally defined IDs from implementation IDs.

AlexSugak commented 8 years ago

Thank you very much for explanation! Seeing the technical solution I didn't think about implications. Will go with in-memory mapping for ids.