[SERVER-39768] add function to stitch library to check if projection has positionals Created: 22/Feb/19 Updated: 29/Oct/23 Resolved: 28/Mar/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.10 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Michael O'Brien | Assignee: | Justin Seyster |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Query 2019-04-08 |
| Participants: |
| Description |
|
This is needed to perform a more complete validation in some cases where a positional projection is incompatible with other params (for example findOneAndReplace/Update with returnNewDocument) |
| Comments |
| Comment by Githook User [ 28/Mar/19 ] |
|
Author: {'email': 'justin.seyster@mongodb.com', 'name': 'Justin Seyster', 'username': 'jseyster'}Message: This includes stitch_support_v1_projection and stitch_support_v1_update. |
| Comment by Justin Seyster [ 21/Mar/19 ] |
|
mpobrien One more question for you: is it likely that you'll want to have a similar function for "update" objects as well? It should be pretty quick to add, so I think it's worth doing if there's a chance it would be useful. [EDIT] I looked into this some more, and I remembered that stitch_support_v1_update_create() already errors if the user creates an update that has a positional but no matcher. For that reason, I think adding a function to see if an update has a positional is probably not necessary. I could still add it, though. |
| Comment by David Storch [ 04/Mar/19 ] |
|
Thanks for the details mpobrien! But why would it be a problem to let the Stitch lib naturally raise an error in the case that the caller supplies both a positional projection and the new:true flag? |
| Comment by Michael O'Brien [ 28/Feb/19 ] |
|
craig.homa We need this in order to be able to properly validate arguments when a client calls the findOneAndUpdate or findOneAndReplace methods. The server disallows positional projections when using returnNewDocument:true so stitch needs to implement the same behavior - without it, we'd need to either accept that if a user does attempt this operation then the update will be executed in the DB but the user will receive an error message, OR we can continue to use the old projection code for now. The priority isn't a blocker, either of the above options i mentioned above are acceptable in the interim but obviously far from ideal so it would be useful to have this in the near term. |
| Comment by Craig Homa [ 28/Feb/19 ] |
|
Hey mpobrien can you please explain why Stitch needs this and comment on the priority? |