Allow nested serialization

[pyeve]

Allow nested serialization

[nicolaiarocci]

Hello and thanks for your suggestion.

MongoDB doesn't provide a native referential integrity/FK mechanism so something like this would need to be abstracted at the application level. Fortunately Eve already supports a data_relation keyword, which allows to (basically) define a RI rule. You would have something like:

DOMAIN = {
     'letter': {
         'schema': {
             author: {
                 'type': 'objectid', 
                 'data_relation': {
                     'collection': 'user', 
                     'field': '_id', 
                     'embed': True
                  },
             },
             subject: {'type': 'string'},
             body: {'type': 'string'}, 
         }
     },

This being said, since there are no JOINS in the MONGO world, such a mechanism would cause a double lookup on the database, for each GET on the resource endpoint. The natural Mongo way to solve this kind of scenario is to just embed the documents within the main document. As a matter of fact, Implementing the embed feature would make Eve something closer to an ORM, but I see the usefulness of such a feature. Thoughts?

[oriolrius]

Hello, IMHO this is very useful because in some schemas it's necessary to do
'application JOINs' embed documents it's not always a good idea for some
operations. There are several scenarios where this is a MUST.

Best.

Oriol Rius

[bcattle]

That's a fair point, regarding ORM. I wonder if this also has negative
RESTful-ness, since there are two ways to access a document: through a
canonical URL (/posts//) and additionally through a collection
(/tags/football/). If a link is broken via the collection URL this doesn't
mean that the entity is gone, merely that it is no longer in that
collection. Since applications could (incorrectly) rely on the "collection
URL" maybe this is best left out.
On Jul 23, 2013 11:41 PM, "Nicola Iarocci" [email protected] wrote:

Hello and thanks for your suggestion.

MongoDB doesn't provide a native referential integrity/FK mechanism so
something like this would need to be abstracted at the application level.
Fortunately Eve already supports a data_relation keyword, which allows to
(basically) define a RI rule. You would have something like:

DOMAIN = {
'letter': {
'schema': {
author: {
'type': 'objectid',
'data_relation': {
'collection': 'user',
'field': '_id',
'embed': True
},
},
subject: {'type': 'string'},
body: {'type': 'string'},
}
},

This being said, since there are no JOINS in the MONGO world, such a
mechanism would cause a double lookup on the database, for each GET on the
resource endpoint. The natural Mongo way to solve this kind of scenarios,
is to just embed the documents within the main document. As a matter of
fact, Implementing the embed feature would make Eve something closer to
an ORM, but I see the usefulness of such a feature. Any thoughts?

—
Reply to this email directly or view it on GitHubhttps://github.com/nicolaiarocci/eve/issues/68#issuecomment-21466612
.

[nicolaiarocci]

An interesting alternative would be to grant clients the power to activate document embedding on per-request basis, by means of a query parameter (or maybe a custom header). A GET like this /invoices/?embedded={"user":1} would return a fully embedded user record whereas the same request without the embedded argument would just return the user ObjectId. The API maintainer could still control what gets embedded:

DOMAIN = {
     'letter': {
         'schema': {
             author: {
                 'type': 'objectid', 
                 'data_relation': {
                     'collection': 'user', 
                     'field': '_id', 
                     'embeddable': True
                  },
             },
             subject: {'type': 'string'},
             body: {'type': 'string'}, 
         }
     }

By default, embeddable would be False (which basically means that client-controlled document embedding is disabled, preserving the current behaviour). This is of course just a raw draft inspired by @bcattle suggestion, what do you guys think about it?

[nicolaiarocci]

Of course, a mix of the two solutions is also workable (explicitly embed a linked document in the settings while setting embeddable proprierty on other linked fields).

[bcattle]

Thanks for the good suggestions Nicola. I like the query parameter idea, because it's consistent with the projection operator, i.e. /people/?projection={"lastname": 1, "born": 1}

This sidesteps the ORM issue by allowing the client to request a particular representation of the data. Just as it does when requesting XML or JSON, all fields or only some.

[bcattle]

Just an update, I have this working experimentally for the case of a one-to-one relationship. I need to write the unit tests. If there's interest I can extend it to one-to-many relationships as well.

[wbashir]

@bcattle +1

[nicolaiarocci]

@bcattle +1 go ahead man, cant' wait!