techfort
commented
9 years ago took me a while to digest it all but this seems like a very good start! My first question is if we should have (similarly to the Flux architecture) a Dispatcher component that digests internal collection events and publishes them. In other words, I'd like to decouple consumers from the Collection, possibly DVs are also going to be consumers?
Secondly, when you say that Collections answer simple queries, do you mean the query engine does a "pass through" to Collection to return a particular record?
Another element I would like discussed is caching, a component that works out frequent queries. In JS it is very easy to do caching:
function process(arg) {
// some complex stuff
}
function processCached(arg) {
var cache = {};
return function () {
if (cache[arg]) {
return cache[arg]
} else {
cache[arg] = process(arg);
return cache[arg];
}
}
}the only adaptation would be to have a dirty flag on the collection data to flush all cache. opinions, suggestions and lapidation all accepted :)
obeliskos
seriousme
and
ArnoBuschmann
ahdinosaur
hampsterx
retorquere
First try on a design:
The idea is that:
The Collections
The query engine
Emitted updates can be used by an adapter to:
Updates can be initiated by:
To avoid long loads during LogAppend restores an adapter could LogAppend to disk, start a new log , do a save of the collection and remove the old log (on success). This will ensure maximum robustness of disk based persistence.
Fire away ;-)