[SERVER-15216] remove() should ignore notablescan Created: 11/Sep/14 Updated: 10/Dec/14 Resolved: 12/Sep/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Write Ops |
| Affects Version/s: | 2.6.4 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Nic Cottrell (Personal) | Assignee: | J Rassi |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: |
| Description |
|
db.Example.remove( {"wordCount":0}) gives
Maybe remove should be an exception to the notablescan setting? |
| Comments |
| Comment by Nic Cottrell (Personal) [ 15/Sep/14 ] |
|
What about an explicity {force: true}option or {notablescan:false}? |
| Comment by Eric Milkie [ 12/Sep/14 ] |
|
"notablescan" does make certain operations impossible; running "remove()" with a query for a non-indexed field is one such operation. I don't think it's prudent to have all the otherwise-impossible operations ignore "notablescan", but neither does making an arbitrary exception for this one operation. |
| Comment by Nic Cottrell (Personal) [ 12/Sep/14 ] |
|
Well, I was doing some cleanup on the collection, deleting invalid objects which were inserting before a new constraint was added in the application. I ended up having to add an index on this field to cleanup then remove it again afterwards. Not a bit problem I guess, but for very large collections which is much more load than a full tablescan, right? |
| Comment by Eric Milkie [ 11/Sep/14 ] |
|
Hi Nic, |