justin-millman / Kvasir / 7952216020 / 2

99%

master: 98%

push

github

Complete Refactoring of Extraction and Reconstitution

This commit is a complete refactoring of the Extraction and Reconstitution layers of Kvasir. While the general design of
these pieces is still the same, the details and specific interfaces/components have been updated to reflect a more
accurate understanding of how they will need to be used. Several pieces of functionality that didn't previously exist
(e.g. being able to reconstitute a struct via default construction) are now available, and a whole new host of
comprehensive unit tests have been written.

In addition to adding functionality that was previously unavailble, this commit fixes two major problems with the
original implementation of Extraction and Reconstitution:

   1. The subsystems did not elegantly handle enumerations, which cannot be stored in a DBValue. When a Field's type is
        Enumeration, it is necessary to convert it to a string for storage in the back-end database; this is true even
       if the back-end RDBMS has dedicated support for Enumerations. The ability to perform this conversion (and, on
       reconstitution, reversion) was not available; in fact, there was no clean way to apply multiple data conversions,
       as would be needed for a Field whose CLR property type is not an enumeration but is converted to one by a
       [DataConversion] annotation, or for either [Numeric] or [AsString].
   2. The lookup functionality for identifying Reference Entities by their Primary Key was busted in two ways. First,
       the caching relied on default hash/equality behavior for C# collections, which is not element-wise; as such, the
       cache would never be properly hit, since the Extraction logic for producing the candidate Primary Key produces a
       brand new collection each time. The bigger bug, though, was that the original implementation passed post-reverted
       values to the look-up unit, while the Extraction logic produced post-converted values. They woul... (continued)

1463 of 1486 branches covered (0.0%)

Branch coverage included in aggregate %.

3177 of 3225 relevant lines covered (98.51%)

1505.41 hits per line