Support for Reciprocal Properties

[justin-millman]

We should add an annotation that lets the user mark the fact that a Field is simply the reciprocal view of a Relation or Reference defined on another Entity. For example:

public class Teacher {
    public int ID { get; }
    public string FirstName { get; }
    public string LastName { get; }
    [Reciprocal] public Class Course { get; }

    // Constructor omitted
}

public class Course {
    public string Name { get; }
    public bool PassFail { get; }
    public Teacher Professor { get; }

    // Constructor omitted
}

In this case, the [Reciprocal] attribute on the Course property indicates that this value is the Class where Class.<some-property> is the Teacher instance itself. Such a property should, by default, NOT correspond to a Field in the backing RDBMS, because it's already encoded by the Course Entity. (Furthermore, storing it in the back-end database would cause a reference cycle, which is not going to be permitted at all in the first version of Kvasir.)

Some things to consider:

• This new annotation will be conceptually similar to the CodeOnlyAttribute, in that it marks a property as one that should not be stored in the database
• Translation will have to figure out how to map the reciprocity by finding the corresponding property on the source Entity/Type
• We will need to support all cardinalities: one-to-one, one-to-many, many-to-one, and many-to-many
• We will need to support multiple reciprocal properties of the same type, which means we'll need some attribute of the annotation to explicitly differentiate the target properties of the reciprocity
• Reconstitution is going to be tough, because the C# code will contain a reference cycle: the instance with the reciprocal property will have to exist first so that the referencing instance can be instantiated, which will be needed to fill in the reciprocal property. We'll probably have to do it in a completely separate step, at the end after all the relevant objects have been created. For references to collection properties, we could theoretically delay Repopulation on the referencing instance until after the referenced instance is created, but that would break the existing Reconstitution model where Repopulation is simply a native part of the "plan." To support this pattern, though, a reciprocal property would have to be writeable, even if only privately. I think that's probably a fair trade-off.
• Does Kvasir need to do anything about consistency? Probably not, that should be the job of the user: Kvasir won't ever look at a reciprocal property unless it's trying to fill it in during Reconstitution.

I think this is a ticket to tackle AFTER the initial v1 release is complete - no reason to attempt to deal with all of this complexity before Translation and Transaction have been completed, since this is all orthogonal functionality.