Add two routeOptions properties modelCustomIdType and modelCustomChildI…

[lucarp]

Add two routeOptions properties modelCustomIdType and modelCustomChildIdType to allow custom id types in generated routes to pass Joi validations.

With this change, one can use different types of _id in different routes.

[JKHeadley]

I really like this idea, and I think it could be beneficial to many users. There are a few things I'm concerned about or unclear about that maybe you could help me think through.

1. It seems that the actual routeOptions properties that are checked are cusomtIdType and customChildIdType rather than modelCustomIdType and modelCustomChildIdType. Is that what you intended?

2. I noticed there is no option for specifying the _id type with the create endpoint, which means it will still default to an objectId. Could you help me understand the type of workflow you are expecting here?

3. I am a bit cautious in adding this feature simply because the _id property is very tightly integrated with many aspects of the framework. For instance, any associations would also need to make sure they reference the correct _id type. You can check out joi-mongoose-helper.js for examples. There might be other situations that would be affected that I can't currently think of.

4. Given that my previous points are accounted for, I would definitely want this feature to be well tested. Unfortunately testing could prove to be a major undertaking considering the amount of integration affected by this feature. The easiest solution might be to duplicate the current end-to-end tests and provide a varied mix of custom _id types to make sure the core features function correctly.

[lucarp]

Hi. I'm working on a API project now, and the point is that I have a third-party service that manages some stuff for me, and gives me a few documents (mongo objects) with associations. These objects ids are strings... my only two options would be to either map external ids to my generated ObjectIds, which would require a lot of effort and coding, or simply import their ids, which is fairly direct and simple. Therefore this idea... About the points you've raised: 1) Indeed..my mistake. I should fix it 2) The `create` routes does not require id's to be objectIds, as long as you explicitly declare _id in the model Schema with a different type. 3 and 4) You are right, it should be done. I have tested myself. I am already using the fork locally... Another option would be to change Joi.objectId() for Joi.any().... it worked just fine... however not ideal, I'll make some tests. How can we work together to make this pull request be accepted? I'm kind of relying on it to go further with my solution. Regards, Em qui, 11 de jan de 2018 às 18:38, Justin Headley <[email protected]> escreveu:

…

I really like this idea, and I think it could be beneficial to many users. There are a few things I'm concerned about or unclear about that maybe you could help me think through. 1. It seems that the actual routeOptions properties that are checked are cusomtIdType and customChildIdType rather than modelCustomIdType and modelCustomChildIdType. Is that what you intended? 2. I noticed there is no option for specifying the _id type with the create endpoint, which means it will still default to an objectId. Could you help me understand the type of workflow you are expecting here? 3. I am a bit cautious in adding this feature simply because the _id property is very tightly integrated with many aspects of the framework. For instance, any associations would also need to make sure they reference the correct _id type. You can check out joi-mongoose-helper.js <https://github.com/JKHeadley/rest-hapi/blob/5aec86df344af589387a2cfbd9246e5a9a1c0d59/utilities/joi-mongoose-helper.js#L67> for examples. There might be other situations that would be affected that I can't currently think of. 4. Given that my previous points are accounted for, I would definitely want this feature to be well tested. Unfortunately testing could prove to be a major undertaking considering the amount of integration affected by this feature. The easiest solution might be to duplicate the current end-to-end tests <https://github.com/JKHeadley/rest-hapi/blob/master/tests/end-to-end.tests.js> and provide a varied mix of custom _id types to make sure the core features function correctly. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#90 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AfhpGlkyzymwr9lMEcEpclPlO97w19p1ks5tJnEggaJpZM4RbK4b> .

[JKHeadley]

Thanks for the explanation. I believe there might be a better solution that involves auto-generating the Joi object based on the actual _id type. I will look into this today and let you know so we can get this feature out ASAP.

[JKHeadley]

@lucarp Just to update, I created a new branch looking into the approach I mentioned earlier. You can take a look at my last commit to get an idea as to what I am trying to accomplish.

I believe this update accomplishes the Joi validation side of custom _ids, however after looking at other parts of the code there are still many areas that will need updating. For example, creating model associations still assumes documents are using ObjecIds for their _ids. I would be happy to work with you on getting this feature implemented, however it looks like its going to take some work.