fix: avoid emitting incorrect metadata for separate-key one-to-one.

Author: ascott18

CHANGELOG.md

@@ -7,6 +7,7 @@
 - `c-input` no longer attempts to delegate shared-key one-to-one properties to `c-select`, a scenario that is not possible to select values for.
 - DTOs no longer generate MapToNew methods with unsatisfied `required` constraints.
 - Fix results from `useResponseCaching` in `ViewModel`/`ListViewModel` `$load` results would get treated as dirty data.
+- Separate-key one-to-one relationships, which already weren't supported by Coalesce, will no longer emit incorrect metadata for the navigation prop on the principal side of the relationship. These properties now emit as "value" properties instead of as "referenceNavigation" properties.
 
 # 6.0.1
 - `createAspNetCoreHmrPlugin` now displays NPM package mismatches with the standard vite overlay instead of a custom overlay.

docs/modeling/model-types/entities.md

@@ -28,7 +28,11 @@ On entities that are the "one" side of a one-to-many relationship, collection na
 
 ### One-to-one Relationships
 
-One-to-one relationships can be represented in Coalesce, but require fairly specific configuration to satisfy both EF and Coalesce's needs. Specifically, the dependent/child side of the one-to-one (the entity whose PK is also a FK), must explicitly annotate its PK with `[ForeignKey]` pointing at the parent navigation property. For example:
+One-to-one relationships can be represented in Coalesce, but require fairly specific configuration to satisfy both EF and Coalesce's needs. Coalesce handles two types of one-to-one relationships:
+
+#### Shared-Key One-to-One (Recommended)
+
+In a shared-key one-to-one relationship, the dependent/child entity's primary key is also its foreign key to the principal/parent entity. The dependent side must explicitly annotate its PK with `[ForeignKey]` pointing at the parent navigation property:
 
 ```c#
 public class OneToOneParent
@@ -47,7 +51,26 @@ public class OneToOneChild
 }
 ```
 
-Alternatively, you could also implement a one-to-one like a normal one-to-many relationship, where both sides of the relationship have their own distinct PK, and just never add more than one child to any particular principal entity. A unique constraint on the foreign key column can enforce the singularity of this relationship.
+The `[InverseProperty]` attribute can optionally be added to the parent's navigation property, but is not required for Coalesce to correctly identify this relationship.
+
+#### Separate-Key One-to-One (Limited Support)
+
+In a separate-key one-to-one relationship, the dependent entity has its own distinct primary key and a separate foreign key property with a unique constraint:
+
+```c#
+[Index(nameof(ParentId), IsUnique = true)]
+public class OneToOneSeparateKeyChild
+{
+    public int Id { get; set; }
+
+    [ForeignKey(nameof(Parent))]
+    public int ParentId { get; set; }
+    
+    public OneToOneParent? Parent { get; set; }
+}
+```
+
+**Important Limitation**: Coalesce cannot fully model reference navigation properties of separate-key one-to-one relationships from the principal/parent side (the side that doesn't own the foreign key). This is because Coalesce can only represent a reference navigation that has a corresponding foreign key property on the same type. Such navigation properties will be emitted as regular "value" role properties rather than reference navigation properties, even if annotated with `[InverseProperty]`. This results in a more limited experience in the [admin pages](/stacks/vue/admin-pages.md) and [ViewModels](/stacks/vue/layers/viewmodels.md)
 
 ### Inheritance (TPH and TPT)
 

src/IntelliTect.Coalesce.CodeGeneration.Api/Generators/ClassDto.cs

@@ -165,7 +165,7 @@ private void WriteParameterDto(CSharpCodeBuilder b)
                     .OrderBy(c => c.Parameters.Count())
                     .Where(c => c.DtoMapToNewConstructorUsage.IsAcceptable)
                     .FirstOrDefault();
-                
+
                 if (bestCtor == null)
                 {
                     var reasons = Model.Constructors
@@ -196,7 +196,7 @@ private void WriteParameterDto(CSharpCodeBuilder b)
                         // If the type has no default constructor but also isn't used as an input by Coalesce,
                         // don't stop code gen - just gen an exception (that will never be hit at runtime)
                         b.Line("throw new NotSupportedException(" +
-                            $"\"Type {Model.Name} does not have a constructor suitable for use by Coalesce for new object instantiation. " +
+                            $"\"Type '{Model.Name}' does not have a constructor suitable for use by Coalesce for new object instantiation. " +
                             "Fortunately, this type appears to never be used in an input position in a Coalesce-generated API.\");");
                     }
                     else
@@ -406,8 +406,8 @@ void WriteSetters(CSharpCodeBuilder b, IEnumerable<(IEnumerable<string> conditio
     /// <param name="modelVar">The variable that holds the entity/model instance.</param>
     /// <returns></returns>
     private IEnumerable<string> GetPropertySetterConditional(
-        PropertyViewModel property, 
-        PropertySecurityPermission permission, 
+        PropertyViewModel property,
+        PropertySecurityPermission permission,
         string modelVar)
     {
         string RoleCheck(string role) => $"context.IsInRoleCached(\"{role.EscapeStringLiteralForCSharp()}\")";
@@ -599,8 +599,8 @@ string mapCall() => property.Object.IsCustomDto
         {
             // Only check the includes tree for things that are in the database.
             // Otherwise, this would break IncludesExternal.
-            string treeCheck = property.Type.ClassViewModel.HasDbSet 
-                ? $"if (tree == null || tree[nameof({dtoVar}.{name})] != null)" 
+            string treeCheck = property.Type.ClassViewModel.HasDbSet
+                ? $"if (tree == null || tree[nameof({dtoVar}.{name})] != null)"
                 : "";
 
             setter = $@"{treeCheck}

src/IntelliTect.Coalesce.Tests/TargetClasses/TestDbContext/OneToOne.cs

@@ -15,8 +15,17 @@ public class OneToOneParent
     [InverseProperty(nameof(SharedKeyChild2.Parent))] // Can be specified, but not required.
     public OneToOneSharedKeyChild2 SharedKeyChild2 { get; set; }
 
+    // Coalesce can't model reference navigations of separate-key one-to-one relationships
+    // from the side that doesn't own the FK, since Coalesce can only represent
+    // a referenceNavigation that has a corresponding foreignKey on the same type.
+    // This will emit as a "value" role, despite having InverseProperty
+    // which would normally make this a referenceNavigation.
+    [InverseProperty(nameof(SeparateKeyChild.Parent))]
     public OneToOneSeparateKeyChild SeparateKeyChild { get; set; }
 
+    // This should also emit as a "value" role.
+    public OneToOneSeparateKeyChild SeparateKeyChildNoIp { get; set; }
+
     public List<OneToOneManyChildren> ManyChildren { get; set; } = [];
 }
 

src/IntelliTect.Coalesce.Tests/Tests/TypeDefinition/PropertyViewModelTests.cs

@@ -354,6 +354,31 @@ public void OneToOne_ChildNavigations_HasCorrectMetadata(PropertyViewModelData d
         Assert.Equal(inverse, vm.InverseProperty.Name);
     }
 
+    [Theory]
+    [PropertyViewModelData<OneToOneParent>(nameof(OneToOneParent.SeparateKeyChild))]
+    [PropertyViewModelData<OneToOneParent>(nameof(OneToOneParent.SeparateKeyChildNoIp))]
+    public void OneToOne_SeparateKey_ParentNavigations_HasCorrectMetadata(PropertyViewModelData data)
+    {
+        PropertyViewModel vm = data;
+        Assert.Equal(PropertyRole.Value, vm.Role);
+        Assert.Null(vm.ForeignKeyProperty);
+    }
+
+    [Theory]
+    [PropertyViewModelData<OneToOneSeparateKeyChild>(nameof(OneToOneSeparateKeyChild.Parent))]
+    public void OneToOne_SeparateKey_ChildNavigations_HasCorrectMetadata(PropertyViewModelData data)
+    {
+        // See comments in OneToOne.cs about what this is all about
+
+        PropertyViewModel vm = data;
+        Assert.Equal(PropertyRole.ReferenceNavigation, vm.Role);
+        Assert.Equal(vm.Parent.PropertyByName("ParentId"), vm.ForeignKeyProperty);
+
+        // We can't model the other side as a reference navigation,
+        // so the inverse property shouldn't be defined.
+        Assert.Null(vm.InverseProperty);
+    }
+
     [Theory]
     [PropertyViewModelData<OneToOneManyChildren>(nameof(OneToOneManyChildren.OneToOneParent))]
     [Description("https://github.com/IntelliTect/Coalesce/commit/513db257dda32b99099355f1a6de0f5fbf367f5a")]

src/IntelliTect.Coalesce/TypeDefinition/PropertyViewModel.cs

@@ -512,24 +512,38 @@ public DatabaseGeneratedOption DatabaseGenerated
             if (prop == null)
             {
                 // If the other side of the relationship is also a reference navigation,
-                // this is a 1-to-1. If there's otherwise no FK specified, assume that the PK
+                // this is a shared-key 1-to-1. If there's otherwise no FK specified, assume that the PK
                 // of this type is the FK we're looking for here.
-                // See test models "OneToOneParent"/"OneToOneChild1" for example.
-
-                if (this.HasAttribute<InversePropertyAttribute>() &&
-                    InverseProperty?.Role == PropertyRole.ReferenceNavigation)
+                // See test models "OneToOneParent"/"SharedKeyChild2" for example.
+                if (this.HasAttribute<InversePropertyAttribute>())
                 {
                     // Only look at `InverseProperty` if explicitly annotated.
                     // Otherwise, this will cause infinite recursion.
-                    return EffectiveParent.PrimaryKey;
+                    if (
+                        InverseProperty?.Role == PropertyRole.ReferenceNavigation &&
+                        // The reference navigation on the other side points at this prop's owner type
+                        InverseProperty.Object == this.EffectiveParent &&
+                        // The FK on the other side must reference this prop's type's PK.
+                        // This is what allows us to think of our own PK as also being a FK
+                        // into the other type (even if that's the exact opposite of the relationship in practice).
+                        // This is admittedly a bit of a hack.
+                        InverseProperty.ForeignKeyProperty?.IsPrimaryKey == true
+                    )
+                    {
+                        return EffectiveParent.PrimaryKey;
+                    }
                 }
-
-                if (Object!.ClientProperties.Any(p =>
-                    p.ForeignKeyProperty == Object.PrimaryKey &&
-                    p.Type == this.EffectiveParent.Type
-                ))
+                else
                 {
-                    return EffectiveParent.PrimaryKey;
+                    // Handle the similar scenario as above, but when InversePropertyAttribute
+                    // is not present. See "OneToOneParent"/"SharedKeyChild1".
+                    if (Object!.ClientProperties.Any(p =>
+                        p.ForeignKeyProperty == Object.PrimaryKey &&
+                        p.Type == this.EffectiveParent.Type
+                    ))
+                    {
+                        return EffectiveParent.PrimaryKey;
+                    }
                 }
             }
         }