dotnet / efcore

EF Core is a modern object-database mapper for .NET. It supports LINQ queries, change tracking, updates, and schema migrations.
https://docs.microsoft.com/ef/
MIT License
13.73k stars 3.17k forks source link

Have YOU tried EF Core 2.2 preview 3 #13716

Closed ajcvickers closed 2 years ago

ajcvickers commented 6 years ago

Download numbers indicate that many of you have not: image

This is the last preview before RTM. We need you feedback now!

So update to the preview--it's on NuGet--run your tests and see what happens.

More info can be found in the announcement post.

Comment here on your experience.

πŸ‘ if you tried it and it worked. πŸ‘Ž if you tried it and it didn't. Please comment on what went wrong. πŸ˜• if you couldn't try it. Please comment on why not.

Please give us the feedback we need to make this a solid release!

ErikEJ commented 6 years ago

Filed a test failure #13707 (may well be unrelated) - otherwise all looks good

velocitysystems commented 6 years ago

Working really well for me, apart from #13708.

As a side note, to serialise/deserialise IPoint objects propery needed to write a simple custom JsonConverter, would be nice to see one shipped in EF Core but I guess that’s outside the scope of the project.

sam-wheat commented 6 years ago

Number 1,537 here.

baoduy commented 6 years ago

it is working fine on my project. Happy to see it release.

image

DSilence commented 6 years ago

Tried it on my project, so far #13686 is blocking further testing. HUGE thanks to EF team for implementing spatial support! Really looking forward to cleaning up all the messy workarounds for spatial types in our codebase.

sam-wheat commented 6 years ago

Confirm fixed: https://github.com/aspnet/EntityFrameworkCore/issues/11561 https://github.com/aspnet/EntityFrameworkCore/issues/11004

Its running like a champ. Thanks guys!

bricelam commented 5 years ago

@mattrichnz Have you considered serializing to GeoJSON? (via the NetTopologySuite.IO.GeoJSON package)

var json = new GeoJsonWriter().Write(point);
Starkie commented 5 years ago

Just did. I confirm that #13531 is fixed. Thanks again!

garvincasimir commented 5 years ago

I changed my NuGet reference from 2.0.0 to 2.2.0-preview3-35497 and only the test for sql server backends failed. https://github.com/garvincasimir/csharp-datatables-parser/commit/e0c2cc4a7cdf841d8cd33ff80ed40a5dc97efb2a https://travis-ci.org/garvincasimir/csharp-datatables-parser/jobs/449127101#L4835

I can provide more context if needed but I am mapping a built-in function.

bricelam commented 5 years ago

SqlException : Cannot find either column "dbo" or the user-defined function or aggregate "dbo.Format", or the name is ambiguous.

garvincasimir commented 5 years ago

For more context, I am pulling microsoft/mssql-server-linux:latest to run these tests. Last successful run was 5 months ago on v2.0.0. Is it possible something changed on the sql server end? https://travis-ci.org/garvincasimir/csharp-datatables-parser/builds/388849731

EDIT: Sql Server version doesn't seem to be the issue. I reverted the EF version bump and the build passes. https://travis-ci.org/garvincasimir/csharp-datatables-parser/builds/449167458

Generated queries: 2.2.0-preview3-35497 WHEN CHARINDEX(N'9/03/1953', LOWER([dbo].[Format]([val].[BirthDate], N'M/dd/yyyy'))) > 0

2.0.0 WHEN CHARINDEX(N'9/03/1953', LOWER(Format([val].[BirthDate], N'M/dd/yyyy'))) > 0

ilmax commented 5 years ago

Everything works for me!

ajcvickers commented 5 years ago

@smitpatel @maumar Any thoughts on the comments above from @garvincasimir?

smitpatel commented 5 years ago

@garvincasimir - It is bug fix as mentioned in https://github.com/aspnet/EntityFrameworkCore/issues/9214 We started to default the schema to dbo on SqlServer for user defined functions since they are required to be schema qualified. In your case you are using Format which is build-in function and should not use schema prefix. It worked in 2.0 due to the bug. In order to make it work in 2.1 or any higher version of EF Core, you would need to specify DbFunction(Schema = "") on your function at https://github.com/garvincasimir/csharp-datatables-parser/blob/50612f69e387156a93634a518c355b8697698a43/test/DatatablesParser.Tests/PersonContext.cs#L14

In the essence any DbFunction which is mapping to a built-in function needs to set the schema to "" to tell EF that it is built in function.

garvincasimir commented 5 years ago

Thanks @smitpatel I figured it was something like that. I guess it is too late since the decision seems to have already been made but I am uncomfortable with adding dbo by default. Users with other schemas would still need to specify the schema. I wouldn't have called the original behavior a bug. I feel like empty (no schema) is a much better default. Specifying schema as an empty string seems kind of awkward. @pmiddleton

smitpatel commented 5 years ago

@garvincasimir - Certainly specifying empty string as schema is bit awkward, but mainline scenario for DbFunction to be user defined functions which are most of times server functions for specific user logic. It is true that DbFunction allows you to map to built-in functions but many of the built-in function on server side are mapped with their appropriate CLR side using MethodCallTranslators in provider code. (like string.Lower/Upper etc). Some of them which does not have specific CLR type mapping has been defined on EF.Functions. So the scenario of user defined function mapping to built-in function on server side remains minority hence, we decided to make "dbo" default.

pmiddleton commented 5 years ago

@garvincasimir - A small point of clarification. The original issue was that DbFunctions were not using the model's DefaultSchema. That is what #9214 fixes. Should you change the DefaultSchema on the model to something other than dbo then DbFunctions will use that.

As @smitpatel stated the majority use case is for mapping user defined functions and therefore we use the models DefaultSchema for Sql Server.

garvincasimir commented 5 years ago

Thanks for the additional context. Makes sense.

On Mon, Nov 5, 2018, 5:58 PM Paul Middleton notifications@github.com wrote:

@garvincasimir https://github.com/garvincasimir - A small point of clarification. The original issue was that DbFunctions were not using the model's DefaultSchema. That is what #9214 https://github.com/aspnet/EntityFrameworkCore/issues/9214 fixes. Should you change the DefaultSchema on the model to something other than dbo then DbFunctions will use that.

As @smitpatel https://github.com/smitpatel stated the majority use case is for mapping user defined functions and therefore we use the models DefaultSchema for Sql Server.

β€” You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aspnet/EntityFrameworkCore/issues/13716#issuecomment-436067513, or mute the thread https://github.com/notifications/unsubscribe-auth/AC9k5zeKHu99jiInDysgQjE3eyhLVwPoks5usMKugaJpZM4XzrW8 .

garvincasimir commented 5 years ago

Seems that this was changed again? EF Core 3.0 seems to be inserting dbo when it finds an empty schema. @pmiddleton

pmiddleton commented 5 years ago

@garvincasimir - this did change.

See https://docs.microsoft.com/en-us/ef/core/what-is-new/ef-core-3.0/breaking-changes#udf-empty-string

garvincasimir commented 5 years ago

Thanks @pmiddleton for the link. So as of now there is no way to call system functions in SQL Server?

smitpatel commented 5 years ago

@garvincasimir - The link also shows example on how to configure DbFunction to call system function.

garvincasimir commented 5 years ago

@smitpatel I saw that but it was listed under "Migrations". Not sure how it would apply to query generation (Linq to Sql).

smitpatel commented 5 years ago

@garvincasimir - It is listed under "Mitigations" (if I understand you correctly).

garvincasimir commented 5 years ago

@smitpatel woops!! I read it wrong (multiple times). I will take a look.