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
Yeah
The names aren't part of the wire encoding though (that would be inefficient)
So on the wire I think the encoding is the same as a record
Emill
@Emill
I looked at how pgAdmin does
Shay Rojansky
@roji
But composite types definitions are loaded by Npgsql ahead of time, and so you can map them to CLR types etc.
Emill
@Emill
when a query returns a column with a specific oid as type, it immediately sends a new query to check what that oid means
Shay Rojansky
@roji
Interesting
Npgsql loads all the type OIDs when it first connects to a database, including all type definitions. So we already know everything when we receive the record
Emill
@Emill
unless the user alters the table in the meantime, or adds a new table...
Shay Rojansky
@roji
This is how we are able to provide the user with an object[] for a record - we know which type each field is in the record, and which type handler can decode it
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.