New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature-request: Allow to define id per collection #1377
Comments
Alternative you could use req.query.id as an option to provide the "id property" for that call? |
Yesterday I submitted a PR for a filter to get the first value for a result set, this combined with routing works as a serviceable work around for id per collection. |
The issue is that with routing you can "define" an id per set, but delete and patch do not consider the routing (for obvious reasons) and so there is - at the moment - no feasible way to have an identifier property different than "id", if you would like to alter the data. For readonly purposes it works just fine. If I find the time and motivation I could implement a PR, however I would like to know which option is more preferable? A) Provide a mapping file "idmapping.json" B) evaluate req.query.id for each call which would use the "ex_id" as identfier for that operation. A) would allow to define one id property for all collections in a compact manner Could also do both, but that implies an order of evaluation, which could get confusing to explain? |
The "routes" feature is only implemented for "GET".
The code that needs to be changed is in server/router/plurals.js line 285 and following.
The "--id" feature is implemented through lodash_id, which allows only to change the property for all collections.
What is needed is a feature that allows to map the "id" of the collection to an arbitrary property.
Like "idmapping.json"
{ "collection_name" : "id_property_name", ... }
The functionality needs to be implemented in destroy and update.
a line like this:
db._.id = getIdForCollection(name);
getIdForCollection() must be implemented with a fallback to argv.id;
Thank you for considering.
The text was updated successfully, but these errors were encountered: