Discussion: Use Codec Composition for Joins

[sinanspd]

Currently schemas that require a Join query are defined similar to the following:

 val decoder: Decoder[Item] =
    (itemId ~ itemName ~ itemDesc ~ money ~ brandId ~ brandName ~ categoryId ~ categoryName).map {
      case i ~ n ~ d ~ p ~ bi ~ bn ~ ci ~ cn =>
        Item(i, n, d, p, Brand(bi, bn), Category(ci, cn))
    }

I would like to argue that this doesn't scale well and isn't very pretty (at least at scale). Given that we already have Codecs for Brand and Category so I think this Decoder should be defined in terms of composition (which as functional idea is also worth iterating once again here).

This would require the SQL objects to be at least package private

Opening the issue for discussion but happy to make a PR if people are open to it

[gvolpe]

Here's my take. SQL schemas and queries evolve differently over time. Thus, Skunk chooses an explicit encoding of Codecs instead of using typeclasses like Doobie does (via Meta, Read, and Write).

This allows you to evolve independently of typeclass instances, without resorting to orphan instances.

Now, in this case, you could choose to re-use the Codecs for Brand and Category in this Decoder, since they fit the shape. But the idea of being defined in a private object is exactly because of the independent evolving nature of SQL queries.

If the Item query only needs the brandName and categoryName, then you already need different decoders.

Anyway, re-using those codecs is still a valid choice, but usually one you need to make with other team members. That's up to you, but in this project, I think it's better to leave things as they are to reflect the ideas the book tries to convey.