Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 20:06
    jabellard opened #2244
  • 20:06
    jabellard opened #2244
  • 19:59

    jeremydmiller on master

    minimal build for CI (compare)

  • 19:54

    jeremydmiller on master

    Updated Marten to 5.4 (compare)

  • 19:41
    dnfadmin commented #1789
  • 19:41
    dnfadmin commented #1789
  • 13:32
    phinett opened #2243
  • 13:32
    phinett opened #2243
  • 10:30
    VilleHakli opened #2242
  • 10:30
    VilleHakli opened #2242
  • 09:32
    elexisvenator commented #2146
  • 09:32
    elexisvenator commented #2146
  • 09:30
    elexisvenator commented #2146
  • 09:30
    elexisvenator commented #2146
  • 05:44
    dnfadmin commented #1843
  • 05:44
    dnfadmin commented #1843
  • May 24 16:20

    jeremydmiller on 5.4.0

    (compare)

  • May 24 16:20

    jeremydmiller on 5.4.0

    (compare)

  • May 24 15:46

    jeremydmiller on master

    bumping the ancillary nugets to… (compare)

  • May 24 15:46

    jeremydmiller on master

    bumping the ancillary nugets to… (compare)

Oskar Dudycz
@oskardudycz
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
It allows to catch breaking changes to the codebase
Tony Karalis
@tonykaralis
I had no idea ndepend had that feature
Oskar Dudycz
@oskardudycz
@jeremydmiller @mysticmind @jokokko I've made a try to update Marten to npgsql 4.1.0
although it seems to be marked as minor, then imho it contains breaking changes (at least to dependencies)
it'll force us to use at least 4.6.1 .NET and JSON.NET in v12
With JSON.NET v12 we observed some performance degradation
and with the .NET we have right now 4.6
I'd feel more safer to make this v4.0, although pragmatically we need to do this upgrade for our users
Thoughts?
about 4.6.1 upgrade I think that we could even make a step forward to 4.6.2 as afair it's the version that microsoft supports
Jeremy D. Miller
@jeremydmiller
@baronfel had warned me on twitter that we would hit that. They might be trying to retrofit some of the missing stuff
Oskar Dudycz
@oskardudycz
They already did with IsTransactionComplete
So big thanks to @baronfel being on the watch
But 4.1.0 is already released so they won't downgrade the references
So we need to leave with that (although I hate this upgrade process)
After we decide what to do with 4.1.0, I’ll also check the 5.0 pre release. I have foreseen more troubles there - so it's better to start preparation and give us and them the chance to discuss the potential issues.
Babu Annamalai
@mysticmind
@jeremydmiller @oskardudycz @jokokko Looks like Npgsql 4.1.0 have broken semantic versioning... Can we restrict the version of Npgsql being used by Marten to 4.0.x? This way we can avoid users raising issues upgrading Npgsql to 4.1.
Thoughts?
Oskar Dudycz
@oskardudycz
Probably we should, as we did with <4.0 some time ago
Although the problem will still remain
Probably some users might want to use a newer version - eg. when they are using it together with the EF or Dapper
Babu Annamalai
@mysticmind
Yeah, but it atleast reduces the surface area the problems...
Oskar Dudycz
@oskardudycz
Yes, at least it will cut some weird bugs questions from the users as we had last time
I’ll prepare the PR for that
I’ll also check if we can drop using Npgsql.json.net package, that’s forcing the JSON.net upgrade