title: Mapping of parent/child relations in OData
body: <p>I have an object model with a parent -> children relation:</p>
  
  <p><a href="http://i.stack.imgur.com/MXgfj.png" rel="nofollow">class diagram</a></p>
  
  <p>The relation is a composition, a parent can have multiple children, a child has always one parent and cannot live without its parent. To persist this data, we serialize it into JSON and use a NoSQL document database (MongoDB) to store it:</p>
  
  <pre><code>{
    "id": 123456,
    "Attr1": "I'm a parent",
    "children": [
      {
        "Attr1": "I'm a child"
      },
      {
        "Attr1": "I'm another child"
      }
    ]
  }
  </code></pre>
  
  <p>Now we are trying to map this model to an OData EDM. We map the parent objects as an entity type. Because the children cannot live on their own but are rather part of the parent we did not want them as entity type but more like a complex type.</p>
  
  <p><strong>When using OData 2</strong>, I am having a hard time, because OData 2 seems to not know about collections of primitive or complex types. As soon as you need to map a "to many" relation, it seems necessary to define the "many"-side of the relation as an entity type in its own right. But when defining the children in my model as an entity type, OData2 requires to be able to address these children on service root level. 
  So the canonical URL of the following object
  <em>httX://host/serviceroot/Parent(1)/Child(2)</em>
  really is something like this:
  <em>httX://host/serviceroot/Child(1,2)</em></p>
  
  <p>See documentation of OData2:</p>
  
  <blockquote>
    <p>"For OData services conformant with the addressing conventions in this section, the canonical form of an absolute URI identifying a single Entry is formed by adding a single path segment to the service root URI. The path segment is made up of the name of the Collection associated with the Entry followed by the key predicate identifying the Entry within the Collection. For example the URIs <em>httX://services.odata.org/OData/OData.svc/Categories(1)/Products(1)</em> and <em>httX://services.odata.org/OData/OData.svc/Products(1)</em> represent the same Entry, but the canonical URI for the Entry is <em>httX://services.odata.org/OData/OData.svc/Products(1)</em>."</p>
  </blockquote>
  
  <p><a href="http://www.odata.org/documentation/odata-version-2-0/uri-conventions/" rel="nofollow">http://www.odata.org/documentation/odata-version-2-0/uri-conventions/</a></p>
  
  <p>For me, OData 2 seems to fit for relational databases, where when objects are connected with a "to many" relation, they are mapped to different tables and every object therefor has its own primary key. In this case, it is easy to address a child object on service root level (<em>httX://host/serviceroot/Child(48346954)</em> (where 48346954 is the DB primary key)) because you can fetch that object directly with SQL means.</p>
  
  <p>However, OData2 seems not to fit for document databases which can store nested object graps as documents (e.g. JSON). Child objects do not need to be independent documents but are rather nested in the parent document. When mapping this to OData and then address a concrete child, you would need to first find the document in which this child is embedded and from there traverse the object graph to the child. A direct fetch of an embedded child is not possible.</p>
  
  <p>What do you think, am I right when stating that OData 2 does not really fit a document oriented database?</p>
  
  <p><strong>When using OData 4</strong>, things change a bit, because OData 4 knows about collections of complex types. So may be I can model my children as complex types. Then I have the "to many" relation of parent to its children as a property of the parent with type "complex collection". Would this be the recommendet way to model dependent and nested child objects?</p>
  
  <p>Is OData 4 better suited to map documents from a document oriented database to a REST interface? Has anyone tried it? Or are there more pitfalls I currently do not see and that make OData 4 not a good choice in my case?</p>