betfair/virtualheap

Framework for replicated objects

virtualheap's Issues

Overrides

From Tom:

A thought just occurred to me re virtualheap. Does CO support overriding a named field with another (i.e. In a MapNode can you simply override one child with another with the same name)? In the MapNode code it looks like you can, so I was wondering if there's anything in Cougar that prevents this.

If it is possible, is it strictly allowed? Presumably all descendants of the overridden child should be removed from the heap, but as it is I don't think that's the case? Maybe we could either strictly forbid overwriting, or if we want to supper it ensure the system handles it robustly. Maybe have new Updates, OverwriteField (and OverwriteIndex, which currently is impossible)

Investigate features from glazedlists

Some of these look like they would be useful to virtualheap:

http://www.glazedlists.com/propaganda/features

Built-in heap / subscription management system

Listeners

Being able to listen for changes in [a sub-set of] the heap, but in the language of the domain.

Filtering

I.e. only sending updates relating to particular nodes / branches of the heap

A special case here is being able to treat nodes within a heap as heaps in their own right (kind of the inverse of #2)

Transformation

Possibly another solution to the situation presented in #2, where scalar values could be transformed to give the same data in a different language / currency etc

Nested heaps

Heaps-within-heaps (better terminology needed? Heap pointers?) - it would be cool if a heap could reference another heap as one of it's nodes. This partially solves the situation where we have multiple heaps where much of the data is identical, with only a couple of fields different - e.g. Presenting the same data localised to different locales. Note this only solves the situation where the shared and unique portions of the heap are entirely within different branches.