New Feature: Nested Relations

[justin-millman]

This feature should NOT be implemented until after v1.0.0 is released and stable.

The current design of Kvasir prohibits nested Relations. I think it would be nice if this were supported, at least in certain circumstances. The purpose of this issue is to idea-vomit everything I'm thinking about right now so that, when I come back to this in several months, I haven't lost all the contemplations.

The use case is pretty straightforward: it should be possible to have a Field on an Entity whose type is e.g. RelationMap<int, RelationList<string>> or RelationSet<(char, RelationSet<DateTime>)>. Conceptually, these should flatten:

• A Field of type RelationMap<int, RelationList<string>> on an Entity of type X would produce a single Relation Table where each row contains (PK[X], Key, Value) but with multiple allowed Value for a given (PK[X], Key). This obviously breaks the built-in uniqueness deduction for RelationMap.
• A Field of type RelationSet<(char, RelationSet<DateTime>)> on an Entity of type Y would produce a single Relation Table where each row contains (PK[Y], Item, Item)

Some things shouldn't be possible: RelationList<RelationList<int>> doesn't make any sense, though OrderedRelationList<RelationList<int>> probably does. I think the delimiting factor is at least one additional piece of information to go with the nested Relation. The nesting should supported to arbitrary depth, being lifted each time.

One issue with doing this will be Extraction and Reconstitution. The RelationExtractionPlan currently assumes that each item in the Relation produces a single row of data, generated by a DataExtractionPlan. This would have to change, since nested Relations would yield multiple rows of data per element. We'd have to build something super recursive, too, since each nesting results in an additional layer of fanout. Reconstitution would be similar, though not nearly as gnarly, since we would still be adding items to the individual Relations one at a time post-construction; the bigger deal would be building out the actual Reconstitution logic to understand the grouping mechanics. (Note that as of this writing, even the basic form of that logic does not yet exist.) I think that the recursive Extraction situation would take care of the nested statuses. It's also possible that a new Plan (or set of Plans) for this use case would be useful.

In terms of generating the necessary Table structures, this feature isn't strictly necessary. One can always have a RelationList or a RelationSet of structs with the correct flattened row layout, you just lose the API niceties of having those be actual C# collections. Since the primary design consideration of Kvasir is to limit users' app design as little as possible, it would be nice to remove this artificial restriction.