[SERVER-25625] Regression: eval command on a non-existing database errors on mongos 3.2 Created: 15/Aug/16 Updated: 06/Dec/22 Resolved: 17/Aug/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.2.8, 3.3.10 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | David Golden | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Done | Votes: | 0 |
| Labels: | regression | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Sharding
|
||||||||
| Operating System: | ALL | ||||||||
| Steps To Reproduce: | 1. Launch 3.2 sharded cluster |
||||||||
| Participants: | |||||||||
| Description |
|
Running eval on an empty database on mongos returns an error on MongoDB 3.2.8 (and 3.3.10), but not on 3.0.12. On 3.0.12:
On 3.2.8:
On 3.3.10:
|
| Comments |
| Comment by Kaloian Manassiev [ 17/Aug/16 ] |
|
Generally, we have been striving towards parity between mongod and mongos. In the case of eval though the problem is the there is no JS parser on mongos as it only serves as a router, so it has no way of knowing what the script is doing in order to behave the same as mongod. Given that eval is on its way to getting deprecated we have no plans on closing that parity gap so I am closing this ticket with "Works As Designed". |
| Comment by David Golden [ 17/Aug/16 ] |
|
If the design is that implicit database creation is a "bad thing" in some cases, then I'd like to see that behavior be the same between mongod and mongos. That said, given the design, I don't understand the rationale. Assuming the user is authenticated to write to a DB, why can one write to a collection in the database and have both spring into existence ("good thing"), but some other operations fail if the database doesn't exist ("bad thing")? That inconsistency seems odd. |
| Comment by Kaloian Manassiev [ 17/Aug/16 ] |
|
The reason for the change in behaviour is described in the linked This didn't use to be the case before 3.2 where every operation against an unknown database would create it. |