Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jul 02 12:40
    phillip-haydon opened #2286
  • Jul 02 12:40
    phillip-haydon opened #2286
  • Jul 01 19:55
    jeremydmiller closed #733
  • Jul 01 19:55

    jeremydmiller on master

    Fix casing of .NET in docs (compare)

  • Jul 01 19:42

    jeremydmiller on master

    little fix for rabbit mq ping p… (compare)

  • Jul 01 18:48
    jeremydmiller closed #2258
  • Jul 01 18:48
    jeremydmiller closed #2258
  • Jul 01 18:48
    jeremydmiller commented #2258
  • Jul 01 18:48
    jeremydmiller commented #2258
  • Jul 01 18:48
    jeremydmiller closed #2284
  • Jul 01 18:48
    jeremydmiller closed #2284
  • Jul 01 18:48

    jeremydmiller on master

    re-enables test for getting inc… unnests id collection in subque… updates locator for flattened e… (compare)

  • Jul 01 18:48

    jeremydmiller on master

    re-enables test for getting inc… unnests id collection in subque… updates locator for flattened e… (compare)

  • Jul 01 18:47
    jeremydmiller closed #2274
  • Jul 01 18:47
    jeremydmiller closed #2274
  • Jul 01 18:47
    jeremydmiller closed #2281
  • Jul 01 18:47
    jeremydmiller closed #2281
  • Jul 01 18:47
    jeremydmiller closed #2282
  • Jul 01 18:47
    jeremydmiller closed #2282
  • Jul 01 18:47

    jeremydmiller on master

    better exception message when u… Excluse parent type from sub cl… Disregarding event streams with… and 2 more (compare)

Oskar Dudycz
@oskardudycz
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
In Marten, we're also trying to avoid breaking changes as much as we can
Tony Karalis
@tonykaralis
I have noticed, trust me its much appreciated.
Oskar Dudycz
@oskardudycz
There is third option, so you provide new implementation as the feature toggle that someone might turn on or of
so eg. class in the new namespace
and then also give some time for users to adapt
But it's more for the contract changes in eg. Rest or events
probably for the packages it won't be super effective, but it's also an option
Then after some time you just remove the old code and remove this feature toggle
Tony Karalis
@tonykaralis
I had never thought of using a different namespace that way, nice one ;)
Oskar Dudycz
@oskardudycz
:+1:
Tony Karalis
@tonykaralis
Just thought of a quick and dirty way of checking the schemas. What if we used a bit of reflection and stored a list of property names and types, then just did a check for any missing properties(which would imply a delete/rename) or any type changes.
We could then register all the classes we want to check (I don't need everything validated, only the ones in the external core library)
Might be a dud, whats your first impression?
Oskar Dudycz
@oskardudycz
That's also an option, but you'd also need to store imho types of properties
as it might also impact deserialization
That'd be similar approach as I suggested with the json schema, but with custom schema format
If it's enough then it's fine, it's usually good to keep the things simple, although in the long term json schema would be imho easier to maintain (as it's common format)
You can also store some sample jsons
and then write the tests to verify if they deserialize properly
Tony Karalis
@tonykaralis
Yes absolutely. If I went down the full blown Json Schema checking route, then I would attempt to come up with a PR for Marten not just for myself.
Oskar Dudycz
@oskardudycz
with the set conditions (eg. all properties are non-default)
Tony Karalis
@tonykaralis
Oscar, you are just full of ideas this morning :D
Oskar Dudycz
@oskardudycz
@tonykaralis we would be grateful for that :)
huh, I usually have too many ideas :P
It would be nice to have in Marten possibility to store json schemas of the documents/events
and then allow user to have opt in to check the schema during storing, appending
or as you said validation
But it's quite some work to provide full-fledged solution