Issue #54 Makes pass/fail of MapUsing explicit #71
Conversation
…xceptions as flow control), add examples.
|
Looks Good! Let me know, when you think the Pull Request is done, so we can merge it upstream. |
|
I just glanced at it from my mobile phone, I will take a deeper look into it tommorow (or sunday 😓) and give some more feedback. What I see definitely makes sense and is very useful. Please go ahead and thanks for contributing! |
|
Added some documentation, but I'm not setup to build rst locally. If you'll check that the docs build and that the new tutorial ("custom mapping") looks okay to you? I think there is some room to expand the tutorial to show how to use secondary maps for mapping non-scalar types (like I do in the Polymorphic example test) -- but I was concerned that diving into that might be overwhelming for someone just trying to get If you're satisfied with this, I'm happy with it & I did re-run all unit tests prior to the PR. I think it'd be great to get NuGet updated for people (as well as myself 😄). As a future extension of this work, there might be some good options to incorporate "secondary" maps into the top-level edit The one decision I think needs made: Should this ship with the old (Action, not Func) MapUsing signatures present but flagged as |
|
I don't think |
|
@dustykline I have updated the License, so it doesn't add my name everywhere. I have built and added the documentation to the gh-pages branch. Uploaded the package to NuGet and it should be listed soon. As for |
|
@bytefish - Awesome! Glad I could help. FWIW, I’m also dad to a young girl with baby 2 on the way, but in between working & dad-ing, I’d be glad to collaborate more on your 3.0/rewrite goals. I really like Tiny compared to Helper, since a lot of my projects target resource-constrained platforms like Xamarin. |
I'd like to see the MapUsing changes for #54 make it to NuGet. I took a look at the existing work and the one place that I think there was some concern was in
CsvRowMapping.TryMapValue, where the measure of whether or not aMapUsingdelegate was successful was based on whether it raised an exception. You had aTODOcomment there saying that "better error handling is a must" -- of course this is true, but the nature of MapUsing is that it embeds user-code within the main parsing loop, so it is implicitly dangerous.My main change here is to change the MapUsing delegate from an
Action<TEntity, TokenizedRow>to aFuncwhich accepts the same inputs but returns a boolean. This allows MapUsing implementers to mark a row as invalid without raising an exception, which would be quite costly inside the main parsing loop.I've updated the existing MapUsing test to show how this works (returning false to invalidate the row). I've also added a new test within Examples to show how Polymorphic rows can be accomplished with MapUsing. I'd be glad to contribute user documentation for this feature too, if you agree it's ready to ship.