Documents can be big.
They can even contain many fields.
Modifying one specific field separately is unfortunately not supported and this is a big predicament
After I got over it, I started to think of clever ways to solve it.
I split my POCOs virtually to 2 parts. The first one handles all the small fields and the other handles the big, heavy and more static stuff (mainly write once). Each part has its own key. Together they constitute the entire information.
My POCO can read either the small key or the big key (or both in parallel) and populate only the members that got fetched. When updating I must be careful not to save the partial POCO in the wrong place as it contains only partial info.
Downsides:
If I need both the big ans small parts I need to make 2 get requests and merge them to one POCO, member by member.
If I need both big and small parts and then I need to modify only the small, I need to nullify the big’s class members before update to prevent them from being saved in the small document.
This solves the issue of one big POCO (that reads the entire document every time) and the issue of 2 separate smaller ones (which split a valid class members and requires double handling).
I hope the situation is clear, basically it is about partial read and partial update a big document to reduce bandwidth, processing power and latency.
Basically, my questions are:
Is there a better way to handle partial updates ?
Is there a way to get only selected fields using .Net SDK ?
Not at the moment, but this should be changing soon! We are in the process of developing an API that allows you to do partial updates on a document. Additionally, N1QL will eventually also (likely) support partial document updates when it’s released or shortly thereafter.
You current approach seems reasonable and it is similar to how others have done partial updates.
Is there a way to get only selected fields using .Net SDK ?
ATM, you have Views and eventually N1QL when it’s released.
That is indeed surprising !
I’m now in the middle of refactoring my entire code base to comfort with CBDB, so which way should I take ?
My app uses much more reads than writes. Views are not suitable for that as they duplicate the data and are pretty not flexible with respect to returned fields. Actually I thought that the native API supports specifying fields in queries and that just .NET doesn’t.
You mentioned that other use my approach with one POCO split to several (2) keys. Do you have any test case that I can learn from ?
