title: Elasticsearch query for getting all nodes of a graph's adjacency list (building graph in javascript)
body: <p>Have a set of ES documents in an index each like</p>
  
  <pre><code>{
      currId: '&lt;some id&gt;',
      prevId: '&lt;some id&gt;',
      parents: ['NULL']
  }
  </code></pre>
  
  <p>where (for the sake of simplifying this example problem) <code>prevId</code> is used when there is only one parent, else use <code>parents</code> (in reality there are other reasons why it is design like this). </p>
  
  <p>So a set of documents like</p>
  
  <pre><code>{currId: '0', prevId: 'NULL', parents: ['NULL']}
  {currId: '1', prevId: '0', parents: ['NULL']},
  {currId: '2', prevId: '0', parents: ['NULL']},
  {currId: '3', prevId: 'NULL', parents: ['1', '2']},
  {currId: '4', prevId: 'NULL', parents: ['1', '2']}
  </code></pre>
  
  <p>imply a graph </p>
  
  <pre><code>   |-- 1 -- |__3
  0--         |__
     |-- 2 -- |  4
  </code></pre>
  
  <p>(sorry if the ascii art is not great (in words: 0 is parent of 1 and 2, which are both parents of both 3 and 4)). Basically, each node has two fields that, combined, contain the full list of that node's parents. <strong>Note that there may be other documents in the index that are not connected to this graph shown here that I would want to ignore in the query</strong>.</p>
  
  <p>Very new to ES, so very hard to think of even where to start to think about this problem. Is there a way that I can query to get all documents that make up a connected component graph using only knowledge of a <strong>single, random</strong> document that is in that component (not necessarily the graph rooted at zero in the example above) (eg. given only info of a single randomly selected node, obtain all of the other connected nodes)?</p>
  
  <p>** Note, this is being done in a JavaScript REST API request to an ES server via axios (<a href="https://github.com/axios/axios" rel="nofollow noreferrer">https://github.com/axios/axios</a>), so things like for-loops and such could conceivably be used (but am trying to avoid that if possible and just use a single query (though I admittedly don't really know what the performance trade-offs would be here)).</p>