New EF.Functions.Collate

[roji]

Closes #8813

[roji]

@smitpatel addressed review comment.

[roji]

Sorry about the previous nonsense, hopefully I got it right this time.

[smitpatel]

@roji be like

[smitpatel]

@maumar to verify

[roji]

@maumar @smitpatel are we waiting for anything in particular here? Would be good to merge this for preview4.

[smitpatel]

Waiting for this.

[maumar]

this is correct - signed off

[roji]

Made abstract, let me know if you have any more comments.

Today @roji be more like:

[ajcvickers]

@roji @smitpatel I haven't read through the comments here but I noticed there are a lot! Is there anything in particular I should take a look at or needs resolving?

[roji]

@ajcvickers I don't think so, from my side everything is fine - just waiting for approval.

[roji]

@smitpatel new version up.

[roji]

Rebased and made collation abstract in migrations tests too (#20646)

[smitpatel]

Can you add internal docs.

[roji]

These seem to be missing from all translators, will submit a separate PR for this.

[smitpatel]

Ignore. I already did this as part of query docs work. I am trying to make sure we have docs for all new stuff.

[roji]

OK thanks!

[smitpatel]

What is the effect of using EF.Functions.Collate on a string column and projecting it out?

[roji]

Assuming I understand your question: the collation aspect bubbles up across projections - does this look good?

SQL Server:

DROP TABLE data;
CREATE TABLE data (
    id INT IDENTITY,
    cs VARCHAR(MAX) COLLATE Latin1_General_CS_AS
);
INSERT INTO data (cs) VALUES ('foo');

SELECT * FROM data WHERE cs = 'FOO'; -- no results because column is case-sensitive

SELECT * FROM (
    SELECT cs COLLATE Latin1_General_CI_AS AS cs
    FROM data
) AS t
WHERE t.cs = 'FOO'; -- returns row because cs projects out with the explicitly-applied collation

PostgreSQL:

CREATE COLLATION cs_collation (LC_COLLATE = 'en-u-ks-primary',
    LC_CTYPE = 'en-u-ks-primary',
    PROVIDER = icu,
    DETERMINISTIC = False
);

DROP TABLE IF EXISTS data;
CREATE TABLE data (
    id INT GENERATED ALWAYS AS IDENTITY,
    cs TEXT COLLATE "POSIX"
);
INSERT INTO data (cs) VALUES ('foo');

SELECT * FROM data WHERE cs = 'FOO'; -- no results because column is case-sensitive

SELECT * FROM (
    SELECT cs COLLATE cs_collation AS no_longer_cs
    FROM data
) AS t
WHERE t.no_longer_cs = 'FOO'; -- returns row because cs projects out with the explicitly-applied collation

[smitpatel]

Nooo. I wanted a test where you are using EF.Collate in projection and if it generates any difference in reading results. (which it should not.)

[roji]

Ohh you mean top-most projection (i.e. on a column that will be read by the client)? If so I'll check that, no problem (did you mean you want actual test code for this?)

[roji]

Do you mean the following (which passes on both providers):

[ConditionalTheory]
[MemberData(nameof(IsAsyncData))]
public virtual Task Collate_column_projection(bool async)
    => AssertQuery(
        async,
        ss => ss.Set<Customer>().Select(c => EF.Functions.Collate(c.ContactName, CaseInsensitiveCollation)),
        ss => ss.Set<Customer>().Select(c => c.ContactName));

If so do you want this in the test suite?

[roji]

@smitpatel @ajcvickers what's your opinion on merging this into the preview4 branch? It would be good to deliver this with the other collation functionality (column/database migration support)

[ajcvickers]

@roji I think it's probably okay just to wait.