Alright, I'll see if I can narrow it down a bit.
Just to sanity check
Simply running select mt_transform_patch_doc('{ "Number": 123, "Arr": [ { "Id": 1 }, { "Id": 2 } ]}', '{"type":"set","value":100000,"path":"Number"}')
Yields {"Arr": [{"Id": 2}], "Number": 100000} in azure and {"Arr": [{"Id": 1}, {"Id": 2}], "Number": 100000} locally
mt_transform_patch_doc is the same for both instances
in docker you might have most recent as it's dev env
while on azure you might have some older
and the patch won't match
(btw.
patch won't match <= nice title for a Hip Hop song)
is it possible that you could get the json from both envs and the exact document structure + document store config?
I'll see if I can debug mt_transform_patch_doc on both sides see where they differ in behavior and go from there. It doesn't seem like it's anything to do with marten in particular though
@mdissel I haven't seen it, but I can tell that in most of my projects I did what I could to not have any attributes in my POCO - for me it's anti-pattern
@mdissel what are your thoughts?
Evening/Morning all. This might be a bone-head question which i think I have the answer to but wanted to confirm. I have class A, which I have registered in my store options. Class A has a property of type Class B amongst other things. I make a change (add a property to class B). I run the schema validation and it doesn't throw any exceptions. My understanding is that only a change in Class A would warrant a schema change and not in Class B. Am I correct?
@tonykaralis
@CodingGorilla @jeremydmiller You have put this into perspective for me. This is extremely powerful. At the same time it has me worried though. I was under the wrong impression that If i ran
AssertDatabaseMatchesConfiguration after adding a property or more critically removing one then I'd get an exception thrown. This was my only way of protecting the database from a destructive change.
To provide a little more context, we have built a single core library which we use across different web apps(different solutions, different clients). Most classes persisted by Marten exist in the respective Web app's assembly, but there are a few which exist in our core library. Deleting a property off of a class in the core library would then result in the change not being noticed in the Web app (and before you know it or dont know it, some data is gone).
@tonykaralis you can always write your own verification
and allow validation for that https://github.com/RicoSuter/NJsonSchema
although right now it's only a concept in my head... ;)
that eg. you'd store json schema somewhere
and then verify if the documents are valid for eg. most recent schema
So write some kind of "contract tests"
To have simple implementation dedicated for your need shouldn't be super hard
Especially if it's run for the tests and to eg. validate if your core changes didn't break anything
then it should be imho fine solution
Absolutely, at the moment any change in order to get to production would require approval and all tests to pass. So at least a junior wont wreck it accidentally. So putting your solution into a test would add that extra check. ;)
so I think that maintaining the json schema
and then validating it should wokr
I had similar tests in my previous project, I stored snapshoted sample jsons
and then made sure that they're valid in the new schema, and all is working fine
I used that to make sure that I didn't provide a breaking change in my contracts