Hi Guys,
In case it might be useful, I have created a Visual Studio package that adds the EventStore support into VS2012.
With this package you can:
-
Create an EventStore projections project (have your projections under source control, etc., just as any other source code)
-
Deploy projections from the project into the EventStore in one click in the VS.
-
Run any projection as a Query and see its result (in JSON).
It is an ongoing work and some of the features I have in mind are not implemented yet, but the basics I mentioned above are already there.
If interested, you can check it out here: https://github.com/AlexeyRaga/esvstools
Things are not implemented yet (but they will be as soon as I have time):
-
A projection node has Enabled, CheckpointEnabled and EmitEnabled properties. These properties are only respected when deploying a new projection into the EventStore, but not in the updating an existing projection scenario.
-
Show the existing projection “real” results (not just run it as a transient query).
-
When first time creating a project, detect the existing projections in the EventStore and automatically pull them into the project.
-
Something else 
I’d love to see your opinions/feedbacks
P.S. I stole the EventStore icons to use it inside this tool, hope the EventStore team is OK with this fact 
Cheers,
Alexey.
Pretty cool I will be playing with it later today.
This is great! I’ll be playing with it this weekend as well.
Cheers,
Chris
Finally took some time to experiment with the eventstore and like it a lot so far. Thinking about using it for a product Im building on behalf of a client, where the core parts are eventsourced. It's offered both as a hosted service and as installed at customer site. I've got some ideas on how to maintain the projections in the latter case, and thought I'd run them by this list to make sure I'm not way off track...
To begin with, my idea is to create a projection per readmodel/view in the system, with simple linkTo's for all applicable events. It seems like to the easiest way to guarantee ordering, performance, and easy replays & subscriptions. Not really using it as a projection, more like a pre-filtered stream. (I guess this could be done using the per-eventtype-streams, but as reordering would add latency I'm not too keen on that)
Ideally I would create these automatically, by inspecting what eventtypes my readmodel requires (already do this for replaying from my custom sql eventstore). As part of install/update these would be created/updated in the eventstore. I'm not really clear on how the projections behave when updated, so any pointers here would be appreciated, to save some experimentation. Can they be updated, or just deleted/re-created for starters?
Thankful for any input, even if it's just "go back to the drawingboard"
/Peter
Can you discuss a bit your actual usecase for views? This can be done but is probably not an optimal strategy (often better is to host outside the eventstore just a bit of code that reads all events and updates sqlserver).
Aside from that I would take a look at Padmin (not to use but to see Apis). Everything with projections is offered through a restful API. People have already built vs integration using API and powershell bindings as well.
Cheers,
Greg
Btw from what you are describing I think a single projection might be better, normally an outside projection is interested based on type. So write a type based projection
Fromall().when({linkto(e.type,e)})
This would give me a stream per type. Then when I have an outside view that needs say inventoryitemcreated and inventoryitemdeactivated I join
Streams/inventoryitemcreated
Streams/inventoryitemdeleted
This results in a stream with then put together. You could obviously dynamically do the joins at runtime.
Cheers,
Greg
Can you discuss a bit your actual usecase for views? This can be done but is probably not an optimal strategy (often better is to host outside the eventstore just a bit of code that reads all events and updates sqlserver).
Yes, sorry for being unclear, the views are written to sqlserver. My idea was to have one stream/projection per writer, so they all have their own unique counter/id. That way I could have a catchup-subscription per writer, and not have to go through all events at startup. (or all the events from the writer that was furthest behind, in case of a shutdown before everything is written). Might not be an issue with the eventstore, but I’ve spent quite a lot of time optimizing the startup for the current implementation, which kinda lead me into this thinking.
Aside from that I would take a look at Padmin (not to use but to see Apis). Everything with projections is offered through a restful API. People have already built vs integration using API and powershell bindings as well.
Great, I’ll have a look.
Btw from what you are describing I think a single projection might be better, normally an outside projection is interested based on type. So write a type based projection
Fromall().when({linkto(e.type,e)})
This would give me a stream per type. Then when I have an outside view that needs say inventoryitemcreated and inventoryitemdeactivated I join
Streams/inventoryitemcreated
Streams/inventoryitemdeleted
This results in a stream with then put together. You could obviously dynamically do the joins at runtime.
Wouldn’t that force me to use the reordering latency? Or is that only in the multi-node scenario?
It’s only needed when sharded/distributed. Even multinode gives ordering assurance.
It’s only needed when sharded/distributed. Even multinode gives ordering assurance.
Ah, thats great.
I’ll do some tests tomorrow and see if this works out (some writers are on their own threads/transactions so I’m not entirely sure on how to handle id/last-event-written-pointer in this scenario.).
How is this different than $et-EventType? Has something changed?