Skip to content

Conversation

deckchairhq
Copy link

There is code specifically to let _id pass through the filter. What is the thinking behind this?

filters = filters ? filters.concat('_id') : filters; // Always send _id property

If you wish to use slugs or other unique tags to reference your objects, internal id's are unnecessary to expose to the public.

In my case, I am exposing the id but wish to expose it as 'id' not '_id'. This is easily achieved on the schema with the following snippet (Mongoose automatically makes 'id' a virtual schema object, which is purely an ObjectId pre-casted to a hex string):

// Set virtuals to true so they are evaluated on all items in a collectio
MySchema.set('toJSON', {
    virtuals: true
});

MySchema.plugin(Filter, {
    readFilter: {
        "public": ['id', 'title', 'location', 'description', 'active']
    }
});

@STRML
Copy link
Owner

STRML commented Jan 21, 2014

The idea behind this was that users of the API would always need to access the internal id of an object so that we could reliably reference the object in further transactions, e.g. PUT requests and relations. I found it tedious to add '_id' to every single object, since it was guaranteed I would need it.

There is probably a better way to expose this - perhaps there should be a default configuration, of fields that are automatically included in every filter, that is defaulted to ['_id']. That way, in the usual case this operates as intended, but can be overridden if you are using your own internal slugs or tags.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants