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

Bug: prepared statement parameter is not produced for any class or object, "incompatible interpolation" is not thrown #1991

Closed
Awethon opened this issue Feb 14, 2024 · 1 comment · Fixed by #2037
Milestone

Comments

@Awethon
Copy link

Awethon commented Feb 14, 2024

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:

sql"""
  SELECT col1, col2, col3
  FROM table_name
  WHERE state = ${MyBoolean.True}
"""

Expected:

SELECT col1, col2, col3
FROM table_name
WHERE state = ?

Actual:

SELECT col1, col2, col3
FROM table_name
WHERE state =

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

@Awethon 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
@satorg
Copy link

satorg commented Feb 14, 2024

I guess this is because ${MyBoolean.True} is observed as MyBoolean.True type, not just MyBoolean.
For example, this change seems fixing the issue:

sql""" SELECT col1, col2, col3
       FROM table_name
       WHERE state = ${MyBoolean.True: MyBoolean}
  """

But I agree that it can be very confusing.

@jatcwang jatcwang modified the milestones: 1.0, 1.0-RC6 Feb 15, 2024
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
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants