Support customization of master-detail record handling #75
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…on of new error handling information and add line number to it.
Also add tests and the xunit Visual Studio runner.
.gitignore updates
Expose TextReader and TextWriter methods
Provide line number in error handler
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Using the fluent layout classes for record configuration, it is almost possible to completely decouple record models from the FlatFile library. The only exception is in the case of master/detail record relationships. This currently requires the use of the interfaces
IMasterRecordandIDetailRecord.In this pull request, I have factored out master-detail record handling into a pluggable mechanism. The stateful side of master-detail tracking can be replaced in its entirety using an implementation of the
IMasterDetailTrackerinterface, or just the checking of whether records are a master or detail and what to do with them can be changed by providing aMasterDetailTrackerBaseinstance with different constructor parameters.The changes should be backward compatible since the default implementation preserves the current behavior.
I have added tests using, somewhat ironically, an attribute-based implementation of master-detail records. It is really just based on the existing master-detail tests.
As a side note, I was not able to execute the tests in Visual Studio until I installed the xUnit Visual Studio runner package.
I welcome feedback and hope that this could be merged.