You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Running into an issue where Speedment is mapping text[] to java.lang.String. Wondering if this is known and expected that I should write my own mapper, or a defect I should raise.
It is indeed from postgres, any type can be made into an Array. In this case I think String[] makes the most sense since you can't use a Collection or else it'll erase the generic type parameter. My attempt at a custom mapper was fruitless however, as I discovered there isn't support for Array types in the way Speedment internally builds up the prepared statement with repeated calls to ps.setObject(...), whereas for Array types you would need to explicitly create the java.sql.Array like conn.createArrayOf(...) and set it with ps.setArray(...).
Also found a small bug in how it generates code for Array types (not surprising given the lack of support) where generated classes use reference equality instead of Arrays.equals(...), similarly for hashCode.
The text was updated successfully, but these errors were encountered:
Running into an issue where Speedment is mapping text[] to java.lang.String. Wondering if this is known and expected that I should write my own mapper, or a defect I should raise.
It is indeed from postgres, any type can be made into an Array. In this case I think String[] makes the most sense since you can't use a Collection or else it'll erase the generic type parameter. My attempt at a custom mapper was fruitless however, as I discovered there isn't support for Array types in the way Speedment internally builds up the prepared statement with repeated calls to ps.setObject(...), whereas for Array types you would need to explicitly create the java.sql.Array like conn.createArrayOf(...) and set it with ps.setArray(...).
Also found a small bug in how it generates code for Array types (not surprising given the lack of support) where generated classes use reference equality instead of Arrays.equals(...), similarly for hashCode.
The text was updated successfully, but these errors were encountered: