-
-
Notifications
You must be signed in to change notification settings - Fork 92
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
Expanding Patch Operations #307
Conversation
This looks awesome, thank you for this contribution @evancjohnson! As long as @mumby0168 is good with this, let's make it happen. Yes, please add tests. As for the |
@all-contributors please add @evancjohnson for code and tests. Thank you 💜 |
I've put up a pull request to add @evancjohnson! 🎉 |
@mumby0168 @IEvangelist I see where _rawPatchOperations is used, the current implementation of InMemoryRepository expects property info to be provided in the internal patch operation. Is this approach reasonable given that the caller can also provide an explicit path? Using the direct path would allow users to patch a nested object. Should the InMemoryRepository use Newtonsoft.Json in some way (I haven't actually looked up if this possible, I believe I have done something like this in the past) to apply the replace operation to the TItem by path removing the need for _rawPatchOperations and instead leaning on the information provided by the PatchOperation |
Hi @evancjohnson yes, from my distant memory the _rawPatchOperations allowed the in-memory repo to support this feature, it was a challenge and I suspect keeping the support for all the patch operations maybe be difficult ... if there is a way to apply the modifications to JSON from the in memory repo that would be great! Check out the json path support on the |
Thanks for the tip @mumby0168. I will do some research on a good approach. I've got a quick questions. How rigid is the InMemoryRepository? Is it expected to perform exactly the same way as CosmosDB? |
Hi @evancjohnson - it's not super rigid. It was intended to be a helper so that you could use it for unit testing, to help ensure other functionality that might rely on the underlying data store. Does that make sense? We know that there are functional gaps, and we're ok with that for now. |
@IEvangelist I'll have time to work on this during the weekend, sorry for leaving it open for so long. |
Will you be able to finish working on this code? |
Hi @MatKumpf - this was something that @evancjohnson was working on, but hasn't updated. If the op is unable to finish this, I could work on it. Unless it's something that you're interested in? |
I won't conceal, it would be one of the most important functionalities for me 😄 So far I have to in few places create my custom connection with container and use the rest of patch operations on it. Edit: I forgot to answer your question. This is the functionality I would like but I'm not sure I fully understand the dependencies that are in this project so I wouldn't take it on myself for the time being :D |
Furthermore, as @mumby0168 rightly points out, supporting all operations in an in-memory repository can be quite difficult and the question is what concessions can be made. |
@MatKumpf @IEvangelist Sorry for the delay friends I have just finished a project and am about to graduate school, so I have much more time. I am pretty close to finishing this one up. I do have a question which is more architectural for David and Billy. Should test host support patch operations? I personally do not believe that it should, and those tests should be run against the emulator. The reason I suggest that due to the fact patch operations have some not at first noticeable quirks. Check the troubleshooting for an example. What are the thoughts on just supporting testing of patch operations internally and not exposing those in the test harness provided by the library? |
This is a decision we've made with some of the other features, as in not to support those features in the in memory implementation I think that is also fine in this case due to the complexity, would you agree @IEvangelist ? |
Hi @mumby0168 and @evancjohnson - I agree with Billy. The in-mem bits are just to help with unit testing, and not intended to be feature complete. |
@IEvangelist @mumby0168 Thank you for getting back to me. I will update the tests and have the in memory repo throw a NotSupportedException when attempting to run the patch operations! |
Hi again @evancjohnson - any updates on this? |
We can always reopen this PR. But it's been nearly a year since it was first introduced. And months since the OP has replied. |
This PR expands the patch operations to support Set, Add, Remove, and Increment.
@mumby0168 I understand this was assigned to you, I hope I am not stepping on your toes, this is just a draft to make sure I haven't overstepped, I will add tests after I know if this PR is needed.
I also had a question about the _rawPatchOperations is it needed?
Fixes #297