Projections and linkTo

Hi everybody…

It seems I’m the first one to post here…

I’m trying to use projections to make a stream of streams as explained by Greg in his presentation at skillsmatter.

The sample code showed on the slide was not uptodate (using _ in js function names) and I tried to get something working like this :

fromAll().whenAny(
function(state, event) {
if (event.streamId.indexOf(‘InventoryItem/’) == 0)
linkTo(‘InventoryItems’, event);

return state;
}

);

The goal here is to find all events saved to streams named InventoryItem/guid and merge them in a InventoryItems stream.

The function is accepted by the EventStore, but I get a error:

No yet Computed

when I try to access the InventoryItems stream using the ClientApi…

What did I miss ?

jeremie / thinkbeforecoding

What you have done pretty much works for me … (I have ditched the / because it didn’t seem to like that in my stream names?)

fromAll().whenAny(

function(state, event) {

if (event.streamId.indexOf(‘InventoryItem’) == 0)

linkTo(‘InventoryEvents’, event);

return state;

}

);

Events saved to /streams/InventoryItem1 , InventoryItem2 etc get added to InventoryEvents as I would expect… however this only seems to happen if running as a “persistent” projection.

Not sure if that is intended behavior or not (maybe only persistent ones get their emitted events written?)

Yeah it works.

Actually it seems only state is managed with other options.

Persistent mode stores events emited, and linkTo is emiting an event containing a link to other event. It makes sens and give a clue how to use emit in other ways…

I still have to figure out how to use thoses links but it doesn’t seem difficult.

Maybe another option with these streams would be to store all events to a ‘InventoryItems’ stream, and use a projection to dispatch events in ‘InventoryItem-id’ streams based on Id property of events ??

What difference would it make ?

For informations:

links have a EventType of $>

and data is an UTF-8 encoded string of eventNumber@streamId

You can then use this to read the actual event data.

Also we are discussing right now creating a special projection for $all. The reason for this is that its a relatively expensive projection to run (it emits on every event you put in). We can optimize this by putting it inside the write instead of waiting for the write to and then doing after.

Actually it works with /, but it won’t mix well with http api…