Skip to content
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

adding better mongoose conflict error handling #168

Merged
merged 1 commit into from
Feb 27, 2017

Conversation

ekryski
Copy link
Member

@ekryski ekryski commented Feb 27, 2017

Summary

This adds better support for mongodb duplicate key errors. It uses regular expression to parse out the offending key and value and creates a better error message out of it.

Other Information

Related to this Automattic/mongoose#2129

Copy link
Contributor

@corymsmith corymsmith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing to note is that this may break other peoples error handling code if they are doing similar parsing currently in their own API / client. I think this is the right way to go though!

@ekryski
Copy link
Member Author

ekryski commented Feb 27, 2017

@corymsmith Yeah, you are right. This likely will need to be a major version release in case people were relying on the error message.

@corymsmith
Copy link
Contributor

:shipit:

@ekryski ekryski merged commit f1aa1a1 into master Feb 27, 2017
@ekryski ekryski deleted the better-conflict-handling branch February 27, 2017 22:45
@ekryski
Copy link
Member Author

ekryski commented Feb 27, 2017

published as v5.0.0

@idibidiart
Copy link

idibidiart commented Feb 27, 2017

@ekryski

Good call.

But can you please clarify to me the difference between this being a good idea and checking for undefined being passed to $push potentially not being a good idea? I would take @daffl view without any hesitation but I'm trying to understand what the role of something like Feathers-Mongoose is. Is it supposed to take care of ALL input that would cause the ODM/ORM to throw an error or ONLY input that is part of the supported query language as @daffl suggested? A little confused as to the seemingly arbitrary distinction.

Ref:
#167 (comment)

@corymsmith
Copy link
Contributor

@idibidiart This isn't doing any validation on inputs, this is merely formatting the error returned from MongoDB

@ekryski
Copy link
Member Author

ekryski commented Feb 27, 2017

Ya. It's a little grey for sure. I started implementing my own error hook to do that change but figured it was better to have that in the core module rather than have everyone need to repeat this in every app that uses mongoose (this should also probably happen in feathers-mongodb because it's an issue with mongo).

It also was more of a security concern as pointed out in #166. Honestly, I would have liked to see this fixed in mongodb or mongoose but since that is very unlikely to happen and that it was leaking DB info, I decided to fix this. It also makes it much easier to customize the error message further in an error hook because now you have the actual offending key/value.

@idibidiart
Copy link

idibidiart commented Feb 27, 2017

Oh I see @corymsmith I misunderstood the context.

I updated the other issue with my guess as to the rationale in that other case... trying to understand the development philosophy by picking on a random sampling of issues may not be the best approach but it's pertinent to my learning process ... Thanks for all the great work btw guys

cc: @ekryski

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