Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 21:25
    dnfadmin commented #1787
  • 21:25
    dnfadmin commented #1787
  • 11:21
    barclayadam opened #2287
  • 11:21
    barclayadam opened #2287
  • 11:04
    dnfadmin commented #1791
  • 11:04
    dnfadmin commented #1791
  • 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
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
I think that it'd be cool feature
Tony Karalis
@tonykaralis
Yeah, i can see all sorts of issues wed need to deal with
Right so I have 2 things to do then, 1st I need to write a quick fix to protect us in the interim. 2nd I am going to try and get the company to allow some time for this, perhaps myself and one of my devs can work on this. Its a long shot but you never know.
Oskar Dudycz
@oskardudycz
:+1:
seems legit :)
Tony Karalis
@tonykaralis
Thanks for your time @oskardudycz
Oskar Dudycz
@oskardudycz
You're welcome, I'm glad that I was able to help :)
ddivita
@ddivita

I need some guidance on searching collections in documents. I have this query:

'var license = "12345"'
'Session.Query<Organization>(o => o.AvailableLicenses.Select(a => a.License).Contains(license))'

I get the error : Marten does not (yet) support this Linq query type

should I change this to: Session.Query<Organization>(o => o.AvailableLicenses.Any(a => a.License == license))?

Oskar Dudycz
@oskardudycz
yes, I'd recommend that
it shouldwork
Even thinking outside marten Any should generate better queries than Select.Contains
as underneath it should translate it to exists (although that's theory of course ;) )
ddivita
@ddivita
Yep, that worked. Thanks @oskardudycz
Oskar Dudycz
@oskardudycz
:+1:
Barry Hagan
@barryhagan

@tonykaralis

Deleting a property off of a class in the core library would then result in the change not being noticed in the Web app

How so? You broke the contract between the core library and its dependency at the assembly level. That will be a source and binary break. If you have types in your Web app derived from core types they will either break when you remove that property or they won't because the property wasn't being used.

I'm not saying there is no need for JSON schema validation, but I tend to rely on the classes as defined in my code and the consumers of those classes. If you removed a property from a POCO and it didn't break anything at a source level, what was it doing for you in the database jsonb?

Tony Karalis
@tonykaralis
@barryhagan you do make a good point. I think the most important issue I am concerned about is someone changing the contract and not realising that this will break other apps. Some apps we are working on may not require a fix or feature until a month later. By that time we realised the breaking change too late. The validation was a quick and immediate way for a developer to know whether they are breaking other apps or not. I do too rely on the classes most of the time.
The schema validation is a tricky one, it requires storing the schema somewhere and then updating only when there arent breaking changes.
Also, there are certain properties which are never used in the 'client' apps, but still need to be persisted so the core lib can make use of them later for calculations. If we dropped one of those properties in the database with valid critical data, even though the app itself doesnt use it, the core does and wed be in a pickle.
Am still trying to find a simple way of providing this check.
Oskar Dudycz
@oskardudycz
Maybe using https://www.ndepend.com?