Comments/suggestions/PRs/etc. welcome
# arrow
b
Comments/suggestions/PRs/etc. welcome
r
Looks great.
I'd like to suggest that once we have arrow meta ready string interpolated queries are type checked and potentially compilable for verification against a schema
So there is an extra layer of type safety in textual queries
Additionally the row mapping operations can potentially be auto derived also when we have the arity support for meta
Since you can go from data class to a tupled result which then is automatically mapped to the data class properties
b
Re: type-checked interpolated queries: I started to think about parameterized queries over the weekend a la Spring's
NamedParameterJdbcTemplate
, but I think the idea of type-checked queries is better still
Re: row-mapping, I'd like to be able to offer an automatic way to do the type conversion, since I think database row to data class constructor is likely to be a very common case
r
I would like to also recommend to take a look at scalaz schema and skewmorph, if this grows into more features there needs to be a means for schema evolutions of some short
b
I'll take a look at both. I hadn't necessarily considered schema evolution as part of this yet because I usually defer those operations to something like Flyway
Also I figured I would start to look at https://tpolecat.github.io/doobie/ (Rob Norris' database FP lib for Scala + cats)
r
Flyway is great but orgs may also choose canonical schema solutions to transform models across other domains beside persistence or db
Doobie is awesome
We use it a lot at 47
b
oh, model transformations for (e.g.) network serialization boundaries or data exchange layers?
r
I hope db4k becomes the Doobie of Kotlin 😀
Yes I ment those kinds of transformations but that can be a separate lib
b
That is a very nice sentiment, but I expect I have years of learning Scala/cats/doobie/etc. before even approaching that point
r
We are porting those libs to Kotlin too in order to have something like Mu
b
sorry, I am unfamiliar with Mu
r
Yep
Making db4k similar to Doobie in features should not be hard with arrow in the upcoming year and we will be happy to help
b
I think my current path forward will likely be to add some sort of minimal named parameter query support while arrow-meta is under development just so I have something to show my colleagues here at work; concurrently, I will dig in to Doobie to learn how it works
r
That sounds good
Doobie works with a custom free Monad
That resembles IO and extends it's operation with more db primitives
b
We had discussed earlier about interoperability of isomorphic functional types between Cats / Arrow via arrow meta, I think? I don't know if it is possible but if the types can seamlessly interoperate then maybe db4k doesn't need to be finished and we can simply use doobie
r
There are issues related to how types are exposed publicly
Every scala call would need wrapping and some that are solely offered via implicits will need to be explicitly passed
Not sure it would be a good user experience or less maintenance than having a pure Kotlin lib
b
My sense is that isomorphic type interoperability could drive one or more Ph.D theses
r
An arrow db lib is something we would pursue in arrow non dependent of the scala runtime
b
^^ that is actually probably the biggest argument for db4k
r
So DB4k if it's not scala based
b
also the issue of joint compilation between Scala/Kotlin is not solved, either, as far as I am aware
r
Yeah, I'd love if this was pure Kotlin because we can introduce it in the ecosystem provided is built on top Fx
And it fits nicely with the rest of arrow
b
++, I will keep working through it, then. I will proceed although my progress will likely be slow
My co-workers have yet to see the light 😄
r
That's great, we'll be happy to help you wherever we can
b
Thanks, I really appreciate that. I expect walking through the custom free monad in Doobie will result in significant enlightenment for me