Skip to content

API review changes#33388

Merged
roji merged 1 commit intodotnet:mainfrom
roji:ApiReview
Mar 27, 2024
Merged

API review changes#33388
roji merged 1 commit intodotnet:mainfrom
roji:ApiReview

Conversation

@roji
Copy link
Member

@roji roji commented Mar 24, 2024

Part of #33220

@roji roji requested a review from a team March 24, 2024 15:56

/// <summary>
/// Generates the projection in the relational command
/// Generates SQL for the projection clause of the given SELECT expression.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The API review has a note to rename GenerateProjection to GenerateFrom, which I think is a confusion with GenerateTables (I did this). I'm not sure what we'd rename GenerateProjection to - it really is the projection of the SELECT (i.e. the part after SELECT and before FROM).

@roji roji mentioned this pull request Mar 24, 2024
45 tasks
@roji
Copy link
Member Author

roji commented Mar 25, 2024

As the internals analyzer graciously reminded me, we do use SqlAliasManager.GenerateTableAlias() in providers (e.g. SQL Server, e.g. when a JSON lookup is transformed into OPENJSON by composing a LINQ operator on a JSON collection. So making SqlAliasManager fully pubternal would mean using internal APIs from providers.

We can at least keep SqlAliasManager (and SqlAliasManagerFactory?) full-public because of this, but only publicly expose APIs that are for provider consumption (as opposed to APIs for overriding/customizing actual alias logic).

Will bring to design.

Copy link
Member Author

@roji roji left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I now remember why I didn't include a check to ensure no aliases are generated after the postprocessing pass has occured... We occasionally need to generate new aliases in SqlNullabilityProcessor; that's in the 2nd part of the query pipeline, and so after post-processing. I debated while implementing if the alias postprocessing run should be moved to the end of the 2nd part of the query pipeline, but we want to keep that as light as possible, and alias post-processing is inherently optional (close gaps).

So for now I'll leave it as it is until we have a good reason to do otherwise (if anyone objects, let me know and we'll revisit).

/// for more information and examples.
/// </para>
/// </remarks>
[Experimental("EF1004")]
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: I'll extract all diagnostic IDs to a centralized place so we can track them etc.

where ns.StartsWith("Microsoft.Entity", StringComparison.Ordinal)
&& !ns.EndsWith(".Internal", StringComparison.Ordinal)
&& !it.Name.EndsWith("Dependencies", StringComparison.Ordinal)
&& it.GetCustomAttribute<ExperimentalAttribute>() is null
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AndriySvyryd note check exemption for services marked as experimental.

@roji roji merged commit bf52827 into dotnet:main Mar 27, 2024
@roji roji deleted the ApiReview branch March 27, 2024 15:46
@AndriySvyryd
Copy link
Member

So for now I'll leave it as it is until we have a good reason to do otherwise (if anyone objects, let me know and we'll revisit).

Just add a comment there, so we take it into account in the future

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants