BJSON ObjectBinary Read/Write Behavior in EOPA inmem Store

[philipaconrad]

Problem Description

How the EOPA inmem store interacts with BJSON ObjectBinary types is currently either wrong or grossly inefficient. This GitHub issue tracks those bad behaviors, and what alternative behaviors we'd like to support instead.

Background

Currently, the EOPA inmem store support storing BJSON types, which is mostly fine. However, one of those types is the ObjectBinary type, commonly used to store serialized snapshots of big data structures efficiently for later reading. Changing a snapshot is expensive, unless the delta patching functionality is used.

Current store.Read behavior

On store.Read calls, EOPA's inmem store would incorrectly paths that involved traversing into an ObjectBinary as "not found". The path would essentially end at the path segment storing the ObjectBinary. This behavior has been at least partially corrected in #266, but it's not implemented for store.ReadBJSON yet.

Current store.Write behavior

On store.Write calls, the current behavior is deeply inefficient-- the ObjectBinary will be converted into a bjson.Object type, and then will have Set(<key>, <item>) called on it. This results in an explosion of allocs if the ObjectBinary was large.

Alternatives:

• Maybe default to generating/updating a delta patch for the ObjectBinary instead?