Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 2019 21:30
    roji commented #2307
  • Jan 31 2019 20:35
    YohDeadfall commented #2307
  • Jan 31 2019 10:20
    capan starred npgsql/npgsql
  • Jan 31 2019 06:10
    SeanFarrow synchronize #2308
  • Jan 30 2019 20:37
    austindrenski commented #2308
  • Jan 30 2019 20:37
    pentagra commented #1445
  • Jan 30 2019 20:33
    SeanFarrow commented #2308
  • Jan 30 2019 20:31
    austindrenski commented #2308
  • Jan 30 2019 20:27
    SeanFarrow commented #2308
  • Jan 30 2019 20:09
    austindrenski labeled #2308
  • Jan 30 2019 20:05
    roji commented #1520
  • Jan 30 2019 19:50
    gyzod commented #1445
  • Jan 30 2019 19:06
    SeanFarrow commented #1520
  • Jan 30 2019 18:54
    roji commented #1520
  • Jan 30 2019 18:53
    roji commented #1520
  • Jan 30 2019 18:52
    roji commented #2050
  • Jan 30 2019 18:45
    Trolldemorted commented #2050
  • Jan 30 2019 18:21
    SeanFarrow commented #1520
  • Jan 30 2019 18:16
    SeanFarrow review_requested #2308
  • Jan 30 2019 18:16
    SeanFarrow review_requested #2308
Shay Rojansky
@roji
Yep
Exactly - on type changes it's the user's responsibility to call ReloadTypes
Emill
@Emill
anyway for pgAdmin it's not an issue to perform extra queries
Shay Rojansky
@roji
Yeah
Emill
@Emill
but Npgsql must be fast for intense workloads
Shay Rojansky
@roji
Yeah. And PG types change pretty rarely, both types and table schemas are relatively static
Occasionally a user comes along and I tell them to call ReloadTypes, but it's quite rare
Emill
@Emill
the binary format for the record type contains the oid for every element
Shay Rojansky
@roji
Yep, it has to. Otherwise the receiver would just get unidentifiable binary data
Emill
@Emill
the only issue is when the record type itself is of a table oid that is not known, since then we don't know that it should be decoded as a record
Shay Rojansky
@roji
Npgsql usually loads all table types (AKA composites) as well at connection time, so again unless a table is created later it's ok
Emill
@Emill
still I get The field 'array_agg' has type 'public.tbl2[]', which is currently unknown to Npgsql.
even though I have LoadTableComposites=true in the conn string...
Shay Rojansky
@roji
That's strange...
It should work
Emill
@Emill
are there like any documentation for the EF Core internals?
a "getting starting" guide for contributors
Shay Rojansky
@roji
Unfortunately not really... sorry :(
We've been talking about doing some docs like that for a long time, but we've never gotten around to that
Emill
@Emill
I guess it would only be me who would read them anyway
Shay Rojansky
@roji
I've given a high-level talk about how the query pipeline works, but I think it's not low-level enough
It's quite possible :)
But I would be very happy to help you get in if you want
But I have to warn you that this specific area is particularly complicated etc.
Also, we're probably blocking on upstream EF support for aggregate functions
(probably, but not sure)
Emill
@Emill
if we could pitch that this is actually a killer feature, maybe aggregate functions would get some more attention?
Shay Rojansky
@roji
I've already mentioned it, and the team already has a lot of other work - plus this is PG-only, so it's understandably a bit more difficult to push through
Aggregate functions are useful in general (for non-PG too), which is why this is probably going to happen for 6.0 - but I don't know when
Let me find the link
Emill
@Emill
Should probably also investigate PG performance. I got this idea like yesterday.
Shay Rojansky
@roji
Here's some exploratory work I did - I took string_agg as a first attempt because it's simpler: npgsql/efcore.pg#1531
This is the work that led to dotnet/efcore#22957
Emill
@Emill
https://docs.microsoft.com/en-gb/ef/core/ ehm maybe remove the word "lightweight"? :)
Emill
@Emill
I guess I'll see if I can step-debug EF as I perform a LINQ query to get a grasp of what really happens.
Shay Rojansky
@roji
Good luck
Lightweight - compared to EF6 :)
Don't hesitate to reach out
Though we should probably take this kind of conversation to private chat or something
Vojtech Machacek
@vmachacek_gitlab
Hello, I wanted to ask when LTree functionality will be released? I was following the update with great anticipation and now we could use it on current project.
Shay Rojansky
@roji
@vmachacek_gitlab if you're referring to the EF Core support for ltree (npgsql/efcore.pg#1592), then that will go out with 6.0.0-preview1, which should be released sometime next week.
Vojtech Machacek
@vmachacek_gitlab
yes, that's what I had in mind, thanks for the info!
Weston
@ronnyek
I was literally going to ask the very same thing. Any ballpark idea of when thats something i could realistically use in prod? Wont hokd anyone to it.. just curious if thats a couple months thing or something different.
Shay Rojansky
@roji
EF previews are generally really stable, and bugs found on them are fixed quickly - so you may want to use 6.0.0-preview1 once that comes out next week. Otherwise 6.0.0 will be out in November.
Adam Quintana
@AwkEng
I'm looking for some tool recommendations for profiling my queries exported from EF Core's ToQueryString() method. I tried using PgAdmin's Query Tool, but it's doesn't seem to like the @ query parameters. Any recommendations are appreciated.
Shay Rojansky
@roji
I think PgAdmin should work, but that's really a very general PG question that's unrelated to Npgsql/EF
Adam Quintana
@AwkEng
PgAdmin doesn't like the "@__<parameter_name>_0='<parameter value>'" parameter declaration and not sure how to modify to make PgAdmin happy. I'm going to try some other DB tools. Since Npgsql is the intersection of PG and EF I was looking for some advice on what the pros use :).
Jean-Marc68
@Jean-Marc68
Hi. I don't know if I'm at the right place, but I try.
I migrate of PostgreSQL version and because of that an old application is not working anymore. Il founded it was not working because it has npgsql v.2.XX and it's not supported by PostgreSQL 13.2. Then I installed the nuget npgsql 5.0.3. There is somme differences I need to correct (for exemple, I had
catch (NpgsqlException NpgsqlEx)
{
if (NpgsqlEx.Code == "23505")
{
what it seems not being supported anymore. How do I need to do to find the code ?
And in the other hand, when I run the debug, on an error, when I try to see the error contents, everything seems to be written in chinese, japonise, or something else I can't reed.
Error Message : 㩤灜楧獮慴汬牥ㅟ⸳畡潴灜獯杴敲⹳楷摮睯⵳㙸尴牳屣慢正湥層潰瑳慭瑳牥灜獯浴獡整⹲?
I'm a little lost. What do I need to do ?
Shay Rojansky
@roji
I have no idea why your messages are in Chinese or Japanese :) But you need to catch PostgresException, not NpgsqlException (PostgresException is the exception thrown for errors reported by PostgreSQL, as opposed to errors raised by Npgsql itself). The property on that is SqlState (Code still exists but is obsolete)
Jean-Marc68
@Jean-Marc68
Thanks. I corrected NpgsqlException ton PostgresException and find SqlState. But exceptions are still in asiatic language. ='(