-
Notifications
You must be signed in to change notification settings - Fork 348
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
Bug: prepared statement parameter is not produced for any class or object, "incompatible interpolation" is not thrown #1991
Milestone
Comments
Awethon
changed the title
Bug: prepared statement parameter is not produced for an instance of enumeratum.EnumEntry
Bug: prepared statement parameter is not produced for any class or object, "incompatible interpolation" is not thrown
Feb 14, 2024
I guess this is because sql""" SELECT col1, col2, col3
FROM table_name
WHERE state = ${MyBoolean.True: MyBoolean}
""" But I agree that it can be very confusing. |
jatcwang
added a commit
that referenced
this issue
May 12, 2024
Remove instances for HNil / EmptyTuple (alone), as they lead to auto-derivation of instances for _any_ case object which leads to incorrect SQL being generated. The fix is to change the base case to product 1s (A :: HNil, or A *: EmptyTuple in Scala 3) - Add more round-trip tests to fully test the logic Fixes #1991
jatcwang
added a commit
that referenced
this issue
May 12, 2024
Remove instances for HNil / EmptyTuple (alone), as they lead to auto-derivation of instances for _any_ case object which leads to incorrect SQL being generated. The fix is to change the base case to product 1s (A :: HNil, or A *: EmptyTuple in Scala 3) - Add more round-trip tests to fully test the logic Fixes #1991
jatcwang
added a commit
that referenced
this issue
May 13, 2024
Remove instances for HNil / EmptyTuple (alone), as they lead to auto-derivation of instances for _any_ case object which leads to incorrect SQL being generated. The fix is to change the base case to product 1s (A :: HNil, or A *: EmptyTuple in Scala 3) - Add more round-trip tests to fully test the logic Fixes #1991
jatcwang
added a commit
that referenced
this issue
May 13, 2024
Remove instances for HNil / EmptyTuple (alone), as they lead to auto-derivation of instances for _any_ case object which leads to incorrect SQL being generated. The fix is to change the base case to product 1s (A :: HNil, or A *: EmptyTuple in Scala 3) - Add more round-trip tests to fully test the logic Fixes #1991
jatcwang
added a commit
that referenced
this issue
May 15, 2024
Remove instances for HNil / EmptyTuple (alone), as this causes auto-derivation of Read/Write instances for _any_ case object which leads to incorrect SQL being generated. The fix is to change the base case to product 1s (A :: HNil, or A *: EmptyTuple in Scala 3) - Add more round-trip tests to fully test the logic - Align names of derivation methods Fixes #1991
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In case when specific enum entry subtype is used instead of general one, doobie constructs a query without any errors but prepared statement parameter is missing.
Code:
Expected:
Actual:
https://scastie.scala-lang.org/4sHHK15QS5Wd2wDftvSJhw
Usually when there's no implicit doobie fails, but for some reason this is not the case for enumeratum.
Seems to work correctly (throws error) in 0.13.4 but doesn't work in 1.0.0-RC5.
UPD: Seems like this issue is not enumeratum specific. It doesn't fail for any class or object in sql interpolation.
https://scastie.scala-lang.org/usOd2T6PTIaJwpY6YTZZYg
The text was updated successfully, but these errors were encountered: