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

Mention nesting tuples #117

Open
d6y opened this issue Apr 20, 2016 · 3 comments
Open

Mention nesting tuples #117

d6y opened this issue Apr 20, 2016 · 3 comments

Comments

@d6y
Copy link
Contributor

d6y commented Apr 20, 2016

In chapter 5, in the nested case class example, we should point out that for >22 columns you can nest the tuple in the mapping to avoid having a >22 tuple:

E.g.,

// Packing a row into the structure we want:
def pack(row: (String, String, (String, String, String), Long)): User =
  User(
     EmailContact(row._1, row._2),
      Address(row._3._1, row._3._2, row._3._3), row._4)

// Unpacking our structure into a row representation:
def unpack(user: User): Option[(String, String, (String, String, String), Long)] = Some(
  (user.contact.name, user.contact.email, (user.address.street, user.address.city, user.address.country), user.id)
)

// We only project the columns we are interested in:
def * = (name, email, (street, city, country), id) <> (pack, unpack)

... the point being that the * projection there has a tree structure too so is only a tuple of length 3, despite containing 6 values.

This is all horrible. Can shapeless make it better?

@d6y d6y added this to the Icebox milestone Apr 20, 2016
@d6y
Copy link
Contributor Author

d6y commented Jul 29, 2016

We should also mention you can define projections for each type you want to nest. Here's an example:

def * = (name, address) <> (Person.tupled, Person.unapply)
def name = (givenName, familyName) <> (Name.tupled, Name.unapply)
def address = (street, city) <> (Address.tupled, Address.unapply)

...where Person is something like case class Person(name: Name, addr: Address)

Note the * projection delegates to the name and address projections. I think they should probably be private, but I've not tried it out.

(from https://groups.google.com/forum/#!msg/scalaquery/agAgJPuXYG8/AMAv04Z2USQJ)

@d6y
Copy link
Contributor Author

d6y commented May 27, 2017

With mapTo in Slick 3.2 I don't think this is relevant anymore.

@d6y d6y closed this as completed May 27, 2017
@d6y
Copy link
Contributor Author

d6y commented Apr 11, 2018

This is still relevant because you just can't write a tuple with >22 elements for the left-hand side of mapTo. So if you want to avoid HLists for some reason, you need these tricks.

@d6y d6y reopened this Apr 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant