State-only projections, and the use of them

EventStoreDB
1

Hi,

I’m currently experimenting with event store (described: here), and I’m trying to make some use of projections that do not emit any events, but just produce state to be read from. As I understand, projections really shine when one needs to correlate data in a way that’s not feasible in, say, SQL, and when someone needs querying SQL-like, one should integrate event-store with external storage.

Such integration should be fairly trivial (especially with new subscription API that allows to get events from specific point, that way our app that is maintaining this integration can easily detect how to be up-to-date), but it seems it’s not that easy to mix both: Event Store state projections (which allow to make get-by-id read models dead easy) and externally stored projections (which allow more sophisticated querying).

Back to my example:

I’ve made IssueReadModel projection, which just goes over all events and build read model that looks like:

{
Reporter: “someone”,
ReportedOn: 2012-12-11
Status: “active”,
TakenBy: “someone else”,
TakenOn: 2012-12-12
}

``

Now, I can fetch it from Event Store by id - simple.

Say I want to display list of issues reported by some user - I wouldn’t maintain such list in Event Store, because I’d have to create many such lists for different types of queries, so I dump them in external storage:

  • listen to all issues events

  • project the events (similar manner to what Event Store is doing), and store in, let’s say: SQL table row (with all SQL query benefits)

  • later on, when other event arrives, I could remember last event number (checkpoint), and use it to recreate read model and apply only new event (again, this is what Event Store is doing also I assume (checkpointing))

It seems easy, but here, I do not even touch the Event Store projections, I’m doing everything on my own! I thought I could reuse IssueReadModel projection, but this would just complicate things:

  1. listen to issues events

  2. when event arrives, use IssueReadModel projection state and store it in your external storage

Now, point 2. cannot be sure that Event Store’ projection state is up to date, so I could either think of something here, or just get back to previous approach…

Am I on the right track that projections really shine when one needs non-SQL-like (from lack of better word) abilities, and when one needs traditional querying than it’s of almost no use?

2

State-only projections that is, I’m aware that event-emitting ones are damn useful everywhere:)

3

I forget what the name of the option is, but projections have a mode where they will emit state changed events every time you change part of the state.

You could have your subscriber listen for those, in order to populate the same data on your external read-models … should be easy enough to translate those events into sql update statements or whatever?

4

However, for a basic readmodel, those events might look alot like your original ones…so unless you are doing something interesting/difficult to build your state, I would probably just do that stuff externally…

5

Bartosz,

As Rich points out, this might be better done externally as you still won’t have the ability to query the state as opposed to just getting it for a known stream.

Cheers,

James