Replies: 1 comment 4 replies
-
|
Sounds reasonable. uPickle has this and calls it |
Beta Was this translation helpful? Give feedback.
4 replies
-
|
Here's a PR implementing it #27 |
Beta Was this translation helpful? Give feedback.
-
|
Should be released in Scalasql 0.1.8 |
Beta Was this translation helpful? Give feedback.
-
|
Great! Thank you 🙏 |
Beta Was this translation helpful? Give feedback.
-
|
Another thanks from the peanut gallery! I will most likely use it as well. |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hey all,
in my code bases I use a lot of new types, often just wrapping a more fundamental type like string or int. I assume that's rather common. If I want to use such a type, I think I currently have two ways to do so:
TypeMapperfrom scratch, which requires at least a bit of understanding of JDBC/SQL. For example, for aString-based type you have to decide betweenCHAR,VARCHARandLONGVARCHAR. Also, you have to know what acast[T]is in SQL.TypeMapperalready there, delegating to it and maybe casting the type somewhere.Both of them involve a bit of boilerplate and don't really signal to the user "you're doing it right".
I suggest adding a simple method to
TypeMapperor its companion object. Maybe something like:Apart from being less boilerplate, the user needs to know basically nothing about SQL/JDBC to know that what they have done is valid. Also, it makes it easier to not care about the dialect you are currently using, because a implicit for the base type should be in scope whenever
DialectTypeMappersare in scope, so it should naturally use the correct one.Any thoughts? Worth it, not worth it?
Felix
Beta Was this translation helpful? Give feedback.
All reactions