How to not project created and updated fields.

[Francisco Corrales Morales]

Hi,

How can I not project the created, updated, etag, or _id fields. ?

I don't want:

{

        "first_name": "francisco",

        "created": "Fri, 18 Oct 2013 16:06:36 GMT",

        "updated": "Fri, 18 Oct 2013 16:06:36 GMT",

        "etag": "330a391f8f1abf37d99d3b9630930067333b3166",

        "_id": "52615c8c11773516c7ad8484",

        "email": "e...@e.com"

},

I want:

{

        "first_name": "francisco",

        "email": "e...@e.com"

},

I have tried:  

 ?projection={ "created": 0}        and  

 'projection': {'first_name': 1,  'created': 0} in the schema definition.

Thanks.

[Nicola Iarocci]

From the projection docs:

"Please note that key fields such as ID_FIELD, DATE_CREATED, DATE_UPDATED etc. will still be included with the payload."

This being said, if you really want your API do behave this way, you could still achieve that by stripping these fields out of the response payload. Just hook a callback to on_fetch_resource() hook. Since your callback will be called before the payload is returned to the client, you can use it to delete unwanted fields.

Nicola

[Francisco Corrales Morales]

Hi,

Great.

But I think, that ID_FIELD, DATE_CREATED, DATE_UPDATED should be able to be set in the projection configuration in each endpoint.

I mean, in Eve you can configure almost everything. Well, why not this one?

Thanks 

[wga...@gmail.com]

Is there any good reason why these fields are included? To me it feels like the designer of the API should be able to withhold things like the DATE_CREATED field.

[nsher...@gmail.com]

I completely agree. Having the ability to exclude the _updated, _created etc. fields should be a default option.

Quick question about the callback workaround, would this impede performance at all?