Annotate metadata for nullability, leaving only builders and conventions #23381

roji · 2020-11-18T16:43:59Z

Here's another bucket of nullability. After this, all of metadata is annotated (core, relational, providers) except for builders, conventions and some remaining internal stuff (which I will do later). I've left some nullability warnings where I think a closer look is warranted.

Feel free to push commits directly to this branch, or I can do corrections if you tell me to.

…entions

src/EFCore.Relational/Metadata/Internal/SqlQuery.cs

src/EFCore.Relational/Metadata/Internal/TableBase.cs

src/EFCore.Relational/Metadata/Internal/RelationalModel.cs

src/EFCore.Relational/Query/RelationalSqlTranslatingExpressionVisitor.cs

src/EFCore.Relational/Query/SqlExpressionFactory.cs

src/EFCore.Relational/Metadata/Internal/Column.cs

src/EFCore.Relational/Metadata/Internal/ColumnMapping.cs

src/EFCore.Relational/Metadata/IDbFunctionParameter.cs

src/EFCore.Relational/Metadata/Internal/ColumnMappingBaseComparer.cs

src/EFCore.Relational/Metadata/Internal/DbFunction.cs

src/EFCore.Relational/Metadata/Internal/DbFunctionParameter.cs

src/EFCore.Relational/Metadata/Internal/TableIndex.cs

src/EFCore.Relational/Metadata/Internal/TableMappingBaseComparer.cs

src/EFCore.Relational/Query/RelationalEntityShaperExpression.cs

src/EFCore.Relational/Query/RelationalQueryableMethodTranslatingExpressionVisitor.cs

src/EFCore.Relational/Query/RelationalSqlTranslatingExpressionVisitor.cs

src/EFCore/Metadata/EntityTypeFullNameComparer.cs

smitpatel · 2020-11-18T17:33:46Z

src/EFCore/Metadata/Internal/EntityType.cs

@@ -1502,7 +1502,7 @@ public virtual IEnumerable<ForeignKey> GetDerivedReferencingForeignKeys()

        private Navigation AddNavigation(MemberIdentity navigationMember, ForeignKey foreignKey, bool pointsToPrincipal)
        {
-            var name = navigationMember.Name;
+            var name = navigationMember.Name!;


Is this safe?

I think so... This private AddNavigation gets called from two sites, where a non-None MemberIdentity is constructed... Do you see a problem?

We may want to think about the design of MemberIdentity to make it friendlier...

Depends on caller. But if we are using just name (rather than memberInfo from MemberIdentity then string parameter could have just worked too.

MemberIdentity.Name should be non-nullable

At least theoretically there's the None value of MemberIdentity. Should Name be non-nullable and just assert for that case?

Add IsNone to replace MemberIdentity.Name == null checks

And either:

Make MemberIdentity.Name non-nullable and throw if it's called on None

Or:

Annotate IsNone and call it before calling MemberIdentity.Name

I think the first option requires less code changes

OK, am doing the first option.

@AndriySvyryd I took a look at this as the last nullability leftover.

First, there seem to be a lot of cases (or enough) where MemberIdentity.Name is accessed and null really is expected. If we make Name throw for null, that means that all those call sites have to be changed to identity.IsNone() ? null : identity.Name, which needlessly complicates the code (this is option 1 above). This needs to be weighed against the gain in removing bangs in sites where we know the identity isn't empty (and don't even need/want to check) - I think it may not be worth it.

We could do option 2 and annotated IsNone while leaving Name nullable, but there seems to be little value in doing that - callers can just as well compare Name to null, instead of checking IsNone.

So I think the best thing may be to leave the code as-is - but let me know what you prefer and I'll do it.

Not totally related, but depending on the above we can also obsolete IsNone, and either introduce HasValue (property instead of method like IsNone, and also positive instead of negative), or better yet, do nothing at all - Name can just be checked directly.

Sure, removing IsNone is fine, even if it means leaving the bangs in

smitpatel · 2020-11-18T17:34:57Z

src/EFCore/Metadata/LazyLoaderParameterBindingFactory.cs

@@ -26,8 +28,8 @@ namespace Microsoft.EntityFrameworkCore.Metadata
    /// </summary>
    public class LazyLoaderParameterBindingFactory : ServiceParameterBindingFactory
    {
-        private static readonly MethodInfo _loadMethod = typeof(ILazyLoader).GetMethod(nameof(ILazyLoader.Load));
-        private static readonly MethodInfo _loadAsyncMethod = typeof(ILazyLoader).GetMethod(nameof(ILazyLoader.LoadAsync));
+        private static readonly MethodInfo _loadMethod = typeof(ILazyLoader).GetMethod(nameof(ILazyLoader.Load))!;


GetRequiredMethod?

So... are we removing GetRequiredMethod in the end?

I can neither confirm nor deny.

So many words to just write NCND

src/EFCore/Metadata/MemberIdentity.cs

src/EFCore/Metadata/ParameterBindingInfo.cs

src/EFCore/Query/Internal/NavigationExpandingExpressionVisitor.ExpressionVisitors.cs

src/EFCore.Cosmos/Metadata/Internal/CosmosPropertyExtensions.cs

src/EFCore.Relational/Extensions/RelationalModelExtensions.cs

src/EFCore.Relational/Metadata/ITableBase.cs

src/EFCore.Relational/Metadata/Internal/DbFunction.cs

AndriySvyryd · 2020-11-18T20:59:27Z

src/EFCore.Relational/Metadata/Internal/RelationalForeignKeyExtensions.cs

@@ -32,7 +34,7 @@ public static class RelationalForeignKeyExtensions
            var principalType = foreignKey.PrincipalKey.IsPrimaryKey()
                ? foreignKey.PrincipalEntityType
                : foreignKey.PrincipalKey.DeclaringEntityType;
-            var principalTable = StoreObjectIdentifier.Create(principalType, StoreObjectType.Table);
+            var principalTable = StoreObjectIdentifier.Create(principalType, StoreObjectType.Table)!;


Bug alert: this and below should use storeObject.StoreObjectType instead of StoreObjectType.Table. Also if principalTable or duplicatePrincipalTable is null this should throw (or return false), basically the same as when principalColumns is null

FWIW the two current call sites for this seem to always pass Table, so this shouldn't cause any trouble currently.

Fixed the above, hopefully as you wanted - if not let me know and I'll correct in a future PR.

It would be better to move the

principalTable is null || duplicatePrincipalTable is null

condition to the next if

No problem, I will do that in the next PR.

src/EFCore.Relational/Metadata/Internal/Sequence.cs

AndriySvyryd · 2020-11-18T22:17:53Z

src/EFCore.Relational/Query/RelationalMethodCallTranslatorProvider.cs

+                return dbFunction.Schema is null
+                    ? _sqlExpressionFactory.Function(
+                        dbFunction.Name,
+                        arguments,
+                        dbFunction.IsNullable,
+                        argumentsPropagateNullability,
+                        method.ReturnType.UnwrapNullableType())
+                    : _sqlExpressionFactory.Function(
+                        dbFunction.Schema,
+                        dbFunction.Name,
+                        arguments,
+                        dbFunction.IsNullable,
+                        argumentsPropagateNullability,
+                        method.ReturnType.UnwrapNullableType());


We don't need 2 different calls. 2nd Function allows nullable schema as parameter. Please revert this change.

It is not annotated in this way The implementation also has a Check.NotNull on the schema... Should this be changed?

@smitpatel am merging as-is for now, we can revisit this afterwards and improve.

src/EFCore.Cosmos/Metadata/Internal/CosmosPropertyExtensions.cs

src/EFCore.Relational/Metadata/Internal/Sequence.cs

src/EFCore/Metadata/Internal/Reference.cs

ghost · 2020-11-19T10:26:52Z

Hello @roji!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (`@msftbot`) and give me an instruction to get started! Learn more here.

ghost · 2020-11-19T13:38:17Z

Apologies, while this PR appears ready to be merged, I've been configured to only merge when all checks have explicitly passed. The following integrations have not reported any progress on their checks and are blocking auto-merge:

Azure Pipelines

These integrations are possibly never going to report a check, and unblocking auto-merge likely requires a human being to update my configuration to exempt these integrations from requiring a passing check.

Give feedback on this

From the bot dev team

We've tried to tune the bot such that it posts a comment like this only when auto-merge is blocked for exceptional, non-intuitive reasons. When the bot's auto-merge capability is properly configured, auto-merge should operate as you would intuitively expect and you should not see any spurious comments.

Please reach out to us at fabricbotservices@microsoft.com to provide feedback if you believe you're seeing this comment appear spuriously. Please note that we usually are unable to update your bot configuration on your team's behalf, but we're happy to help you identify your bot admin.

smitpatel · 2020-11-19T17:54:48Z

src/EFCore/Query/Internal/NavigationExpandingExpressionVisitor.ExpressionVisitors.cs

                    if (navigation != null)
                    {
                        return ExpandNavigation(root, entityReference, navigation, convertedType != null);
                    }

                    var skipNavigation = memberIdentity.MemberInfo != null
                        ? entityType.FindSkipNavigation(memberIdentity.MemberInfo)
-                        : entityType.FindSkipNavigation(memberIdentity.Name);
+                        : memberIdentity.Name is not null


Not to worry, I will revert this in the next PR.

Annotate metadata for nullability, leaving out only builders and conv…

922a714

…entions

roji requested review from smitpatel and AndriySvyryd November 18, 2020 16:43

Fixup

92b3738

roji commented Nov 18, 2020

View reviewed changes