-
Notifications
You must be signed in to change notification settings - Fork 357
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
1.0.0-RC6: import doobie.implicits._
is not source compatible.
#2104
Comments
Managed to write an even shorter reproducer. The issue is with the combination of a field wrapped in |
Thank you for the report & repro @notxcain! I think I know what needs to be done to fix this 🔨 |
Awesome! Thanks for the enormous effort with the RC6 🤝🏼 |
Hello @jatcwang , at our company, we're loving users of Doobie. We were considering to update to RC6, but it seems like it's better to wait for RC7. Do you think RC7 will be released sometime this or next week? |
Hey @sideeffffect I'm knee deep in implicit prioritization land right now trying to sort it out 😄 I'm currently trying a variation of Circe's |
Thank you @jatcwang for all your hard work ❤️ Hang in there and good luck! 🍀 |
So..the good news is the general approach works. However, while testing I discovered that because doobie has always relied on auto-derivation. You can not simply take a |
Would you consider marking 1.0.0-RC5 as the https://github.com/typelevel/doobie/releases/edit/v1.0.0-RC5 |
Good idea thanks. Done :) |
Just a quick update. The rework on Write/Read seems to have panned out and there's a clear path forward, I'm working on having it it all working across Scala 2 & 3 + better test coverage of the edge cases |
Fix both semiauto and automatic derivation to use custom defined Read/Write instances (e.g. in companion objects). A complete rework of Read and Write is unfortunately necessary because with the previous implementation, we cannot simply derive a `Read[Option[A]]` given a `Read[A]` - we'd need to derive `Option[A]` from scratch by resolving `Read[Option[X]]` instances for each of `A`'s columns. After the rework, both `Read` and `Write` are now sealed traits, each with 3 subclasses: - Single: Wrapper over a `Get/Put` - SingleOpt: Wrapper over a `Get/Put`, but is nullable i.e. `Read[Option[A]]`, `Write[Option[A]]` - Composite: A composite of `Read/Write` instances Apart from enabling proper semiauto and automatic derivation, the rework also brings these benefits: - Derivation rules are much simpler (which also translates to faster compile times). In particular, given a `Read/Write[A]` we can trivially derive `Read/Write[Option[A]]`. - We now correctly handle optionality for `Option[CaseClassWithOptionalAndNonOptionalFields]`. More tests will be added for this in a follow up PR to demonstrate Other notes: - Semiauto and Auto derivation of unary product type (e.g. 1 element case class) are removed due to it causing auto derivation to pick the wrong path. It seems unnecessary since Write/Read derivation will yield the same behaviour anyway? Fixes #1054, #2104
It looks like the imported auto-derivation takes precedence over explicitly defined instances available in scope when
Option
is involved.Reproducer:
Scastie
The text was updated successfully, but these errors were encountered: