-
Notifications
You must be signed in to change notification settings - Fork 30
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
Support raw/un-typed documents? #188
Comments
Hi, I say the best approach would be a non-generic You could have gone with extension methods using So the best one probably is what you did, as long as the code is shared between the types and not types versions. Happy to review a PR |
I've had the need to work with databases where the type of the documents can't be known beforehand, even based on a known document ID convention. This is because some document types have multiple versions, and the version isn't part of the document ID, and the client application that generates the documents could get updated and create or require documents with a newer version which has a different internal structure.
I've solved this in my fork with the following additions, but it feels a bit dirty
Since the rest of the library is nicely typed, I still have to work with an
ICouchDatabase<TSource>
even though I'm not using theTSource
type constraint for anything. Not a big deal but it's not the end of the world.I had three options that I could think of, either work with an
ICouchDatabase<object>
and then use reflection to work out the object's layout, or add in the *Raw methods to work with the document contents directly, or introduce a non-genericICouchDocument
which just works with untyped data.The simplest approach at the time was to add in the *Raw methods and then parse them into
JObject
s in my application code. I had considered returning and acceptingJObject
s instead ofstring
s, but that adds an explicit dependency on Newtonsoft in the interface which would make a migration to System.Text.Json a lot more painful.This of course has meant that I've had to work with a fork which I've been lazy about keeping updated with the main repo, so I'm looking for feedback as to whether this would be something useful to submit a PR for (with the above methods), or if I should change the approach before doing so. If there's no appetite for supporting something like this then I'll look into moving these methods out into an extensions library instead
The text was updated successfully, but these errors were encountered: