title: storing non-root table of flatbuffers object for later deserialization
body: <p>Consider the following flatbuffers schema (from <a href="https://stackoverflow.com/questions/51806080/deserialize-flatbuffers-binary-that-represents-non-root-table">this stack overflow question</a>):</p>
  
  <pre><code>table Foo {
      ...
  }
  table Bar {
      value:[Foo];
  }
  root_type Bar;
  </code></pre>
  
  <p>Assume the number of <code>Foo</code>s in a typical object is significant so we want to avoid modifying schema to make <code>Foo</code> the <code>root_type</code>.</p>
  
  <p><strong>Scenario:</strong></p>
  
  <p>A C++ client serializes a proper flatbuffers object and posts it to another component (nodejs backend) that partially deserializes the object and stores the binary representing every <code>Foo</code> in a database as separate documents:</p>
  
  <pre><code>const buf = new flatbuffers.ByteBuffer(req.body)
  const bar = fbs.Bar.getRootAsBar(buf)
  for (let i = 0; i &lt; bar.valueLength(); i++) {
    const foo = bar.value(i)
    let item = {
      'raw': foo.bb.bytes_ // &lt;-- primary suspect
    }
    // ... store `item` as an individual entity (mongodb doc)
  }
  </code></pre>
  
  <p>Later, a third component fetches the binary data stored in "raw" key of the mongodb documents and tries to deserialize it into a <code>Foo</code> object:</p>
  
  <pre><code>auto mongoCol = db.collection("results");
  auto mongoResult = mongoCol.find_one(
      bsoncxx::builder::stream::document{}
      &lt;&lt; "_id" &lt;&lt; oid &lt;&lt; bsoncxx::builder::stream::finalize);
  // ...check that mongoResult is not null
  const auto result = mongoResult-&gt;view();
  const auto&amp; binary = result["raw"].get_binary();
  std::string content((const char*)binary.bytes, binary.size);
  const auto&amp; foo = flatbuffers::GetRoot&lt;fbs::Foo&gt;(content.c_str());
  </code></pre>
  
  <p><strong>The problem:</strong></p>
  
  <p>But the pointer given as <code>foo</code> does not point to the expected data and any operation on <code>foo</code> potentially leads to segfault or access violation.</p>
  
  <p><strong>Suspicions:</strong></p>
  
  <p>I speculate that the root cause is that the binary that is stored in the database uses offsets according to the original message. So it is essentially invalid in its own original format and the offsets should be readjusted before inserting into database. But I do not see any flatbuffers function API to readjust the offsets?</p>
  
  <p>One less likely root cause may be that the final deserialization code is incomplete and we have to readjust the offsets?</p>
  
  <p>The reason I suspect it is related to offsets is the fact that this same code works just fine if we make a compromise and post smaller flatbuffers objects with one Foo element in every Bar vector (and change backend code to store <code>bar.bb.bytes</code> in <code>raw</code> instead).</p>
  
  <p><strong>Question:</strong></p>
  
  <p>In any way, is it even possible to grab part of a larger properly constructed flatbuffers binary file that you <em>know</em> represents your desired table and deserialize it on its own?</p>