Skip to content
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 to ignore specific field in patchers #161

Open
Krever opened this issue Apr 11, 2020 · 1 comment
Open

Allow to ignore specific field in patchers #161

Krever opened this issue Apr 11, 2020 · 1 comment
Labels
blocked Ticket cannot be implemented because it depends on another ticker or external factor dragons ahead Task which requires handwriting compiletime reflection for Scala2&3 and/or updating the architecture enhancement

Comments

@Krever
Copy link

Krever commented Apr 11, 2020

Right now it is possible to ignore all the redundant fields in the patcher with ignoreRedundantPatcherFields which is significantly unsafe.

I think it might be a good idea to allow to specify the fields to be ignored explicitly. My current use case below contains 3 different possible uses of such a feature.

case class Foo(id: FooId, a: String)
case class Bar(id: BarId, b: Int)
case class MyPatch(id: FooId, a: Option[String], b: Option[Int])

val (foo, bar p): (Foo, Bar, MyPatch) = ???

foo.using(p).ignoreFields(_.id, _.b).patch
bar.using(p).ignoreFields(_.id, _.a).patch

First, the most obvious one is that I want to ignore redundant fields (a when patching Bar and b when patching Foo). This can be achieved with ignoreRedundantPatcherFields yet with explicit specification I'm safe from the situation when I add a field and its omitted from patching accidentally.

Second is that I ignore id when patching Foo because I already know its the same value. Or at least I assume so and if this assumption is wrong (due to a bug) I may end up with a very weird state once data is patched including this id field.

Third is that Bar also contains a field named id which I not only don't want to patch but also this field is of a completely incompatible type. Currently, I have to fall back to copy as I don't know any workaround for this part.

@MateuszKubuszok MateuszKubuszok added the dragons ahead Task which requires handwriting compiletime reflection for Scala2&3 and/or updating the architecture label Oct 23, 2023
@MateuszKubuszok MateuszKubuszok added this to the Merge transformations milestone Dec 19, 2023
@MateuszKubuszok
Copy link
Member

Depends on #538 which in turns depends on #115.

@MateuszKubuszok MateuszKubuszok added the blocked Ticket cannot be implemented because it depends on another ticker or external factor label May 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked Ticket cannot be implemented because it depends on another ticker or external factor dragons ahead Task which requires handwriting compiletime reflection for Scala2&3 and/or updating the architecture enhancement
Projects
None yet
Development

No branches or pull requests

2 participants