-
-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow extra fields in Patcher classes that don't exist in original #98
Conversation
Codecov Report
@@ Coverage Diff @@
## master #98 +/- ##
=======================================
Coverage 93.64% 93.64%
=======================================
Files 7 7
Lines 362 362
Branches 59 59
=======================================
Hits 339 339
Misses 23 23 Continue to review full report at Codecov.
|
Thanks for great proposal! The guard for fields existing in patch case class, but non-existing in target class was intentional and it was to increase type safety / confidence against stupid typos. I agree we could have some tests that explicitly express the intention ;) Your proposal is kind of similar to proposal from #64 (comment) that assumed providing custom function to patchers that allows to combine target value from new one (from patch) and old one (from existing target). The conversion from Do you think it's crucial to support re-named fields in patchers as well? |
To answer the last question first, in my specific case, renamed fields aren't crucial. The proposal in #64 does seem very useful, and could be used for my particular case (although i'd be throwing away the Looking at it again, I'm assuming the types would have to be the same, so that might not work for my case after all. Anyway, not sure about exact details, but if types could be different or there was to be a new patching syntax and we could mark fields as ignored, I could work with it |
I assumed types don't need to be literally equal, but there exists chimney transformation for them. But you're right in your case it would not work (unless you put your custom mapping logic into implicit transformer in scope which is... meh, not the best idea :P). So we need to find an API that is able to express really custom logic. What about this one? user
.with(userPatch)
.enableIncompletePatches // don't emit compile error when you find a field that doesn't match the target
.withFieldValue(_.roleIds, (old: Set[RoleId], patch: UserPatch) => ...)
.patch |
Sorry - got busy. That proposal looks great! I think it would solve all sorts of use cases. |
@krzemin is this functionality already implemented? or can we build some dsl that fit this? |
There was a specific check put in to guard against this behavior, but no tests ensuring this was the behavior - so thought maybe it could be changed.
Example scenario: we have an api, and want to update a user. The user can specify any of the user fields to update. I'd like to use most of the fields to patch the user, but there's some that need massaging first.
In this simple case, I want to use the
UserUpdate
class to patch theUser
class, even though I have to handle the verification/conversion/patching ofroleNames
intoroleIds
myself.It may be that this should be handled through some flag or some enhanced patch api with transformers or something, just wanted to start the discussion.