Day II of the evented Github adventure

Stupid question…

Based upon the beginning of Greg’s recent Skills Matter talk and the above comment, I am getting the feeling that I shouldn’t be using projections to build read models.

Why not?

Thanks,

James

They are intended for CEP + stream based queries. There is no “show me the states that have firstname starting with L”. Document dbs as well as other forms of dbs already do an amazing job on this kind of query.

Greg, thanks for the quick response…

In some previous logic that I’ve written, my read models were only accessible via their id or by returning all documents in the collection.

I didn’t have any search/query capabilities off the style you described (firstname starting with L).

If I take away the ‘returning of all documents in the collection’ capability, I am only retrieving single documents.

Given this thought pattern above, I don’t see what’s wrong with using the projections system to generate these type of read model documents.

Not to be a pain, but am I still missing something?

No it would fit … However if you break that model, I warned you :slight_smile:

I’m doing something similar to this in order to build one of my graphs on my Github adventure and it doesn’t feel too wrong

That is, “Build all the aggregated data needed for GraphX into this projection for this day”

then all I have to do is

/projections/day-20121113/state

and I have the data required to draw a line graph or whatever

Doesn’t feel wrong, so it must be right :slight_smile:

Its certainly possible if you want to use it as key/value. Things will work fine in that case. The problem comes about when people want to start querying over the key/values (like say OLAP)

To do the queries, would you then simply write a background process that subscribes to relevant streams and updates a couchbase/elasticsearch/whatever database accordingly?

for those types of queries absolutely (and this is relatively easy to do)

That sounds like what I was planning to do for this situation…