support for nested resources

[ahdinosaur]

a resource should be able to contain a resource instance within any of its properties. this is currently possible with using ids as a placeholder for child instances, but then it takes multiple requests to create or get the entire root instance.

[Marak]

Do you mean implementing relational resources?

Here is the API from last time I did this: https://github.com/flatiron/resourceful/wiki/Relational-Resources

[ahdinosaur]

yes.
i feel like this could be implemented directly in the schema. a one-to-one relationship is when a property of a resource is of type resource. a one-to-many relationship is when a property of a resource is an array of type resource. will think about it more, thanks for the link.

[Marak]

JSON-Schema has support in the spec for defining relationships between resources.

see: http://json-schema.org/links

There seems to be a few ways to achieve this. Googling: "defining relationships between JSON-Schemas" yields some good results.

Regardless of whatever resource api we expose to add relationships, the internal representation should comply to a standard. ( being links / hyper-schema / linked-data / etc )

[erobit]

I would love to see graph supported relationships, so we can eventually persist these to a graph db as well!
http://docs.neo4j.org/chunked/milestone/graphdb-neo4j-relationships.html

[ahdinosaur]

related issue: 1602/jugglingdb#251

resource needs support for hasOne, hasMany, belongsTo, hasAndBelongsToMany. it's a pain to use without this basic functionality when trying to make anything beyond the most simple of resources. jugglingdb has direct support for hasMany, belongsTo, and hasAndBelongsToMany.

possible implementation, to provide support for these relations while keeping the relationships defined within the schemas, based on http://json-ld.org/spec/latest/json-ld/#embedding. after thinking about it, i no longer think this will work but i'm keeping it anyways. i think we should just use what jugglingdb has. what i propose fails because it doesn't take into account the doubly-linkedness of relationships. i'll think about it more and maybe it can be fixed.

---

let's say we have a resource tool with properties

tool.property('description', {
  description: 'description of tool'
  type: 'string'
}
tool.property('durability', {
  description: 'measure of how durable the tool is',
  type: 'number'
}

now for a creature to hasOne tool.

creature.property('mainHand', {
  description: "tool in creature's main hand",
  type: 'tool'
}

now if we .get a creature instance as _creature, _creature.mainHand should be the tool object of the creature's mainHand. _creature.save should save both the creature object and the mainHand object.

---

let's assume the same tool resource. now for a creature to ``hasMany` tools

creature.property('bagContents', {
  description: "tools in creature's bag",
  type: 'array',
  items: {
     type: 'tool'
  }
}

now if we .get a creature instance as _creature, _creature.bagContents should be an array of tool objects of the creature's bagContents. _creature.save should save all related objects.

---

TODO: belongsTo, hasAndBelongsToMany

my thoughts would be to define as properties in the reverse object, maybe we can do something like http://json-ld.org/spec/latest/json-ld/#reverse-properties. however one important piece of functionality from belongsTo is that