Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Options classes should subclass the driver options classes #1364

evanchooly opened this issue Jul 4, 2019 · 0 comments


None yet
1 participant
Copy link

commented Jul 4, 2019

Is your feature request related to a problem? Please describe.
By subclassing, we can remove a barrier to exposing new features as the driver evolves. This requires that the driver make these types non-final. A patch will be generated once work has approached completion on the Morphia side. If that patch is not accepted, then composition will be used instead. This doesn't let us track new options seamlessly but it does not rely on the driver team's acceptance of any change requests.

Describe the solution you'd like
Because of the fluent nature of the API, we'll need to override each method and return the Morphia type instead to support Morphia-specific options (read preference, write concern) not typically present on the driver types. Tests will need to be written to ensure that each method exposed by the driver is overridden with the new return type.

@evanchooly evanchooly added this to the 2.0.0 milestone Jul 4, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.