Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 25 12:53

    oskardudycz on 2353

    (compare)

  • Nov 25 12:53

    oskardudycz on 2353

    (compare)

  • Nov 25 12:53
    oskardudycz closed #2396
  • Nov 25 12:53
    oskardudycz closed #2396
  • Nov 25 12:53
    oskardudycz commented #2396
  • Nov 25 12:53
    oskardudycz commented #2396
  • Nov 25 09:13

    github-actions[bot] on gh-pages

    Documentation Update for 7.0.1 (compare)

  • Nov 25 09:12

    Hawxy on master

    Update docs pipeline (compare)

  • Nov 25 01:58
    mysticmind commented #2388
  • Nov 25 01:58
    mysticmind commented #2388
  • Nov 25 00:50
    NikiforovAll commented #2388
  • Nov 25 00:50
    NikiforovAll commented #2388
  • Nov 25 00:49
    NikiforovAll commented #2388
  • Nov 25 00:49
    NikiforovAll commented #2388
  • Nov 25 00:45
    NikiforovAll commented #2388
  • Nov 25 00:45
    NikiforovAll commented #2388
  • Nov 24 16:53
    mysticmind assigned #2400
  • Nov 24 16:53
    mysticmind assigned #2400
  • Nov 24 16:45
    mysticmind labeled #2400
  • Nov 24 16:45
    mysticmind labeled #2400
Tony Karalis
@tonykaralis
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?
Mark Warpool
@CodingGorilla
What kind of schema change are you asking about? None of it would change the database structure to change.
@tonykaralis
Jeremy D. Miller
@jeremydmiller
What he said. There’s no change to your schema. Everything goes into the data field;) That’s the killer advantage of something like Marten or Raven or Mongo over an ORM + relational DB
Tony Karalis
@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).
Oskar Dudycz
@oskardudycz
This will only assert if you changed document configuration to eg. have index
@tonykaralis you can always write your own verification
Tony Karalis
@tonykaralis
Yeah makes sense now.
Oskar Dudycz
@oskardudycz
although it might be quite time consuming, because each document might have different schema
Tony Karalis
@tonykaralis
Yeah thats one way of doing it
Oskar Dudycz
@oskardudycz
I was thinking about the possibility of storing the json schema
and allow validation for that https://github.com/RicoSuter/NJsonSchema
although right now it's only a concept in my head... ;)
Tony Karalis
@tonykaralis
Very interesting :thumbsup:
Oskar Dudycz
@oskardudycz
As for now you could try to implement your own wrapper
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
Tony Karalis
@tonykaralis
I am using Martens subtyping as well though. I have about 15 classes going into a single table.
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. ;)
Oskar Dudycz
@oskardudycz
Understood
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
Tony Karalis
@tonykaralis
Out of interest, what would you do when they werent valid? Lets say you added a property which in my case would be fine, the test still fails?
Oskar Dudycz
@oskardudycz
I think that it would be nice to have built-in feature related to that in the Marten, but because of our capacity that probably happen soon
That depeneds, normally adding property is not a breaking change until it's not required
or if it's required than it has default value, so the flow will continue to work
Rename, or removing the property without doing fallback would be for me breaking change
Tony Karalis
@tonykaralis
So upon validating the json schema, it would allow the addition of properties through
Oskar Dudycz
@oskardudycz
In my case - yes
although it depends of the exact schema change
Tony Karalis
@tonykaralis
Got ya
Did you ever encounter a breaking change? So your schema check test failed but you ended up having to keep the breaking change
Oskar Dudycz
@oskardudycz
If you're adding new property then to make old documents work then you need to provide some kind of fallback or migration. Fallback is eg. the default value or some logic if the data is not filled.
I think that it's safer and in the long term faster to not make breaking changes
But sometimes it happens
so there might be various solutions for that
Tony Karalis
@tonykaralis
I hear you
Oskar Dudycz
@oskardudycz
  1. The easiest is to publish prerelease package with the breaking change so the package clients might be prepared and then when all confirm that they have the code prepared then release the package.
  1. Longer, but better. Send at first non-breaking change so the new payload together with the old one and try to handle both. You mark also old one as obsolete. Then you can have "contract" with the clients of your package (especially if they're other teams in your company) that they have eg. 2-4 weeks to adapt, then you'll remove the old payload.
at least that's the scenarios that I'd suggest
Tony Karalis
@tonykaralis
Thank you Oscar, i think I like this one the most >I think that it's safer and in the long term faster to not make breaking changes
Oskar Dudycz
@oskardudycz
Plus it's always good to provide some explanation or migration guide if this is the breaking change