Support raw/un-typed documents?

[dhirensham]

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

Task<string?> FindRawAsync(string docId, bool withConflicts = false, CancellationToken cancellationToken = default);
Task<TSource> AddRawAsync(string documentId, string content, bool batch = false, CancellationToken cancellationToken = default);
Task<TSource> AddOrUpdateRawAsync(string documentId, string content, string? revisionId = null, bool batch = false, CancellationToken cancellationToken = default);

Since the rest of the library is nicely typed, I still have to work with an ICouchDatabase<TSource> even though I'm not using the TSource 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-generic ICouchDocument which just works with untyped data.

The simplest approach at the time was to add in the *Raw methods and then parse them into JObjects in my application code. I had considered returning and accepting JObjects instead of strings, 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

[matteobortolazzo]

Hi, I say the best approach would be a non-generic CouchDatabase, however, it's a lot of effort to do and maintain it. The Raw methods seem a bit dirty, too, as all methods support that or dynamic or none.

You could have gone with extension methods using NewRequest, but I get that you need to copy-paste the body of FindAsync, for example.

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