-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Latest builds incompatible with some PostgreSQL array scenarios #17374
Comments
How is the query getting translated to server eventually? (if this error did not happen) |
I've got some pattern matching logic in a simple method translator which identifies it and produces the following: SELECT COUNT(*)::INT FROM ""SomeEntities"" AS s WHERE array_length(s.""SomeArray"", 1) > 1 Basically I need the the expression to make it all the way to translation... |
@roji How breaking is this for Postgres? (i.e. We need to decide whether we're going to try to take this in ask mode, or whether we fix it in 3.1.) |
Well, it prevents translation of several array operations, including inside JSON documents (the new feature). Specifically, this prevents translating Any and Contains. It would definitely be a shame to not have this - but I guess it's not completely critical if this goes into 3.1 instead? |
In our projects we are using pg arrays and jsonb fields extensively. For us this is a breaking change that would prevent us from upgrading to preview 9 and 3.0 release. For now, on preview 8 all working fine. |
@SonicGD just making sure - as far as I know this is only blocking the translation of |
Yes. We have many queries like query.Where(e => e.SiteIds.Contains(site.Id)); and they are failing with
|
Thanks for confirming. Note that 3.1 will be coming out quite quickly after 3.0, and this is definitely planned to be fixed for that release - so even at worse case you're not going to be waiting for long. |
Having similar regression here too after updating to 3.0 and preview9 of PostgreSQL in array join such as:
and the error from this is:
|
@thepra - join with client side array is not supported since that join has to be client eval. It has no correlation with PostgreSQL arrays. |
@smitpatel what's the alternative then in this brave new world? |
@thepra - That query was doing client evaluation before. And now we don't do that implicitly. Query should be rewritten for explicit client eval.
|
@smitpatel mmmmm, quite inefficient then pulling all the records and then joining it, but I guess this is how it was before implicitly. |
@thepra yes, the important point is that this is the same behavior as in 2.x, but the inefficiency was being hidden by client evaluation - it is now much easier to understand what's going on. If I'm reading your code correctly, _userService.AppUserPicturesStatic.Where(a => allUsersIds.Contains(a.AppUserId)).ToList() Unfortunately Contains on an array currently doesn't work (that's what this issue is about), but this is planned to be fixed for 3.1.0. Another more extreme option is to use the CREATE TABLE numbers_table (num INT, name TEXT);
INSERT INTO numbers_table (num, name) VALUES (1, 'name1'), (2, 'name2'), (3, 'name3');
SELECT num, name FROM numbers_table JOIN (SELECT unnest(ARRAY[1, 3]) AS arr_num) AS arr_table ON arr_num = num; EF Core will not generate this kind of advanced, PostgreSQL-specific SQL, and most probably never will. However, you can use raw SQL to write it yourself and have EF materialize the results back to entity instances. |
@roji There's no issue on that, I can alter that array to a list. Still, moving to 3.0 have broken many of such similar queries. |
This is true and we're aware of the one-time porting pain that disabling client evaluation may cause. We do believe it's the better way for EF Core to function, as it makes perf issues much more visible and improves compatibility across versions.
You should be able to use Join, but you must use it on entity types rather than on array parameters as you tried above. |
@thepra can you please open a new issue with a minimal code sample (and schema) that shows the problem? |
Great, thanks for confirming. |
Our EnumerableToQueryable converter works on all the methods. But during nav expansion, we actually inject query sources. If item is not a query source (like postgre arrays or collection property mapped as scalar via value conversion), then we convert it to enumerable again to be handled by provider. Resolves #17374
Our EnumerableToQueryable converter works on all the methods. But during nav expansion, we actually inject query sources. If item is not a query source (like postgre arrays or collection property mapped as scalar via value conversion), then we convert it to enumerable again to be handled by provider. Resolves #17374
Our EnumerableToQueryable converter works on all the methods. But during nav expansion, we actually inject query sources. If item is not a query source (like postgre arrays or collection property mapped as scalar via value conversion), then we convert it to enumerable again to be handled by provider. Resolves #17374
Our EnumerableToQueryable converter works on all the methods. But during nav expansion, we actually inject query sources. If item is not a query source (like postgre arrays or collection property mapped as scalar via value conversion), then we convert it to enumerable again to be handled by provider. Resolves #17374
好大一个坑,好惨 |
When syncing EFCore.PG to latest preview9, some array scenarios are now breaking.
Exception:
Query:
Expression tree before NavigationExpandingExpressionVisitor:
Basically NavigationExpandingExpressionVisitor freaks out when it sees a queryable method (AsQueryable) on an array.
/cc @smitpatel
The text was updated successfully, but these errors were encountered: