@ericgreenmix provided few fixes recently to related issues
@oskardudycz I will get that into our next release!
https://jasperfx.github.io/marten/documentation/events/schema/#configuration - docs regarding
UseAppendEventForUpdateLock flag
@malscent if you could revisit that with new version and this flag turned on then that'd be great
Eric found few issues related to distributed events publishing
Hey, I ran into a difference in behavior using Patch<T>(id).Set("prop", value) when running pgsql 11 with plv8 2.3.11 locally in docker vs a paas instance in azure. The document had a nested array like
{
"prop": "v",
"prop2": {
"arr": [1, 2, 3]
}
}
Locally the document is updated as expected but in the cloud instance the array is emptied of all but one element.
Ideas?
if you could provide some more detailed repro then we could have a look
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... ;)