Closed ajcvickers closed 2 years ago
Filed a test failure #13707 (may well be unrelated) - otherwise all looks good
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.
Number 1,537 here.
it is working fine on my project. Happy to see it release.
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.
Confirm fixed: https://github.com/aspnet/EntityFrameworkCore/issues/11561 https://github.com/aspnet/EntityFrameworkCore/issues/11004
Its running like a champ. Thanks guys!
@mattrichnz Have you considered serializing to GeoJSON? (via the NetTopologySuite.IO.GeoJSON package)
var json = new GeoJsonWriter().Write(point);
Just did. I confirm that #13531 is fixed. Thanks again!
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.
SqlException : Cannot find either column "dbo" or the user-defined function or aggregate "dbo.Format", or the name is ambiguous.
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
Everything works for me!
@smitpatel @maumar Any thoughts on the comments above from @garvincasimir?
@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.
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
@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.
@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.
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 .
Seems that this was changed again? EF Core 3.0 seems to be inserting dbo when it finds an empty schema. @pmiddleton
@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
Thanks @pmiddleton for the link. So as of now there is no way to call system functions in SQL Server?
@garvincasimir - The link also shows example on how to configure DbFunction to call system function.
@smitpatel I saw that but it was listed under "Migrations". Not sure how it would apply to query generation (Linq to Sql).
@garvincasimir - It is listed under "Mitigations" (if I understand you correctly).
@smitpatel woops!! I read it wrong (multiple times). I will take a look.
Download numbers indicate that many of you have not:
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!