Playframework with SLICK and 22 column constraints

Question

I am evaluating the Play structure and learning Scala, which was fun. Coming from java, the transition to Scala took a fair bit of psychological gymnastics, but now I'm a fan.

I have a significant database already mapped to using JPA, and I was just about to continue to use this code (with hibernation), however this is not the best or recommended approach with Scala. So I started matching some tables with SLICK, but before I went too far, I realized that I ran into problems with Scala restrictions for classes and functional parameters (no more than 22).

I find it completely incomprehensible that modern ORM will have this limitation. I have no problem with Scala with this limitation - after all, who wants to pass 22 parameters to the function. Therefore, my question is: why create a library with this limit? Surely this should have been designed to match ordinary classes? I don't care if he even used reflection to do the job.

I have seen workarounds for this that require class separation and recombination using implicit conversion. But this is just a hack.

I assume that if I want to continue using Play, then I should switch to Java and use JPA.

Answer 1

This is a weirdly numbered restriction, most likely because the Scala programming language limits the maximum size of tuples to 22, and tuples are a good way to represent table rows. See Why are Scala functions limited to 22 parameters? for more information. There has been some talk about removing this limitation in Scala 2.11 (and supposedly in Slick), and there is an open issue for tracking , but this has not happened since recent releases of 2.11.

I'm not a Slick developer, and I'm sure they could create an ORM based on something without limitation, like List instead of Tuples. Here is my hypothesis about why this happened.

• Typesafe did not want to create ORM from scratch, so it adapted Slick from ScalaQuery, which was one of the most stable and widespread ORM packages for scala.
• ScalaQuery found it necessary to use tuples as a key part of the design.
• ScalaQuery felt that tables with more than 22 columns are somewhat rare.
• He felt that the projection of these tables, which draw more than 22 columns, was even less common.
• Typesafe is working on removing 22 prefixes from Tuples (and functions), and this is necessary for Scala, and once this is done, Slick will no longer have problems with 22+ column tables. Since the problem needs to be fixed in Scala, it makes sense to do this than create a new ORM and work with the community to accept it.