[CXX-1389] Provide consistency to write concern Created: 10/Jul/17 Updated: 07/Feb/24 |
|
| Status: | Backlog |
| Project: | C++ Driver |
| Component/s: | API |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Yoann Couillec | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | bg-rf, rb-track | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| Epic Link: | C++ Developer Experience Improvements |
| Description |
|
in the current API. write concern are managed by only one class, beside the fact that several roles has been identified (https://docs.mongodb.com/manual/reference/write-concern/)
The consequence is that it leads to lack of consistency states for write concern objects. Furthermore, the documentation of the API should explicitely provide which state to avoid ... All that can be solved by building consistent states. And this can be obtained with a clean classes hierarchy that declare a class for each identified role. |
| Comments |
| Comment by Yoann Couillec [ 06/Oct/17 ] | |
|
Concerning the idea of immutable write concern, I definitely agree. This keep control of the encapsulated values. | |
| Comment by Yoann Couillec [ 06/Oct/17 ] | |
|
Hello Derick. I am glad you ask. General observation
The main issue is the usage of all-in-one classes. A class that does everything. The biggest issue is that it leads to inconsistent states. But the checks can only be performed at runtime. The problem can be solved by defining class hierarchies instead of all-in-one classes A good demonstration is write concern. Write concernThe ` w` field of write concernsFirst of all, there are several identified levels of acknowledgements. However there is just one class/structure representing them all. The identified roles are:
SpecificationThe specification defines `w` as:
While `String` concerns both tags write concerns and majority ones. So actually, we have here 4 levels of interpretation:
Here is the semantics of this field Source code of mongoc(xx)To catch up the inconsistencies, a function has been defined (mongoc_write_concern_is_valid) with a respectable goal "Checks to see if @write_concern is valid and does not contain conflicting options." When a call to `mongoc_write_concern_is_valid` is performed, the operation is abandoned and an exception is raised. With a class hierarchy, there is no need to check inconsistency at runtime and no need to raise an exception. | |
| Comment by Derick Rethans [ 28/Sep/17 ] | |
|
HI, Sorry for only just getting to this. Could you give an example of what can currently go wrong, in your opinion? And, how the class hierarchy could work? Right now, the different levels don't really inherit from each other. Do you think that an API as the PHP driver has makes more sense? (See: http://php.net/manual/en/mongodb-driver-writeconcern.construct.php) cheers, |