[SERVER-23237] Write an applyOps dbhelper to directly access the DB without going over the network Created: 18/Mar/16 Updated: 06/Apr/16 Resolved: 06/Apr/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | Dianna Hohensee (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Sharding 12 (04/01/16), Sharding 13 (04/22/16) |
| Participants: |
| Comments |
| Comment by Dianna Hohensee (Inactive) [ 06/Apr/16 ] |
|
LocalClient is no longer being implemented. |
| Comment by Dianna Hohensee (Inactive) [ 21/Mar/16 ] |
|
Yes, I think all the direct storage engine access functions (find,update,applyOps,etc.) that I'm writing will probably end up better placed elsewhere. I figure I'll implement them in dbhelpers ASAP, so they can be used, and then once the framework you're working on devising is in place they can be moved to more appropriate classes. |
| Comment by Spencer Brody (Inactive) [ 18/Mar/16 ] |
|
While you will surely need a helper method for running applyOps for use by the config server for chunk modifications, I don't think dbhelpers.h is the right place to put it. It's not a generally useful method - there should be no callers of it outside of the catalog manager. I feel like this just belongs as a private method on the local ShardingCatalogManager once it exists. |