Playframework with SLICK и ограничение 22 столбцов

Question

Я занимаюсь оценкой платформы Play и изучаю Scala, которая была веселой. Исходя из java, переход на Scala занял довольно немного умственной гимнастики, однако я теперь поклонник.

У меня есть значительная база данных, уже сопоставленная с использованием JPA, и я просто продолжал использовать этот код (с гибернацией), однако это не лучший или рекомендуемый подход с Scala. Поэтому я начал сопоставлять некоторые таблицы с помощью SLICK, но, прежде чем заходить слишком далеко, я понял, что столкнулся с проблемами с ограничениями Scala для классов и параметров функции (не более 22).

Я нахожу это совершенно непонятным, что современный ОРМ будет иметь это ограничение. У меня нет проблем с тем, что Scala имеет это ограничение - ведь кто хочет передать 22 параметра функции. Поэтому мой вопрос: зачем создавать библиотеку с этим лимитом? Разумеется, это должно было быть спроектировано для сопоставления с обычными классами? Меня не волнует, если он даже использовал рефлексию, чтобы выполнить свою работу.

Я видел обходные пути для этого, которые требуют разделения классов классов и рекомбинации с использованием неявного преобразования. Но это всего лишь взломать.

Я предполагаю, что если я хочу продолжить использовать Play, тогда я должен переключиться на Java и использовать JPA.

Answer 1

Это странное пронумерованное ограничение, скорее всего, потому, что язык программирования Scala ограничивает максимальный размер кортежей до 22, а кортежи - прекрасный способ представления строк таблицы. См. Why are scala functions limited to 22 parameters? для получения дополнительной информации. Были некоторые разговоры об устранении этого ограничения в Scala 2.11 (и, предположительно, в Slick), и есть an open issue to track it, но этого не произошло с недавними релизами 2.11.

Я не разработчик Slick, и я уверен, что они могли бы создать ORM на основе чего-то без ограничения, как List вместо Tuples. Вот моя гипотеза, почему так получилось.

• . Виды оборудования не хотят создавать ORM с нуля, поэтому адаптированный Slick от ScalaQuery, который был одним из самых стабильных и широко распространенных пакетов ORM для scala.
• Автор ScalaQuery счел нужным использовать кортежи в качестве ключевой части дизайна.
• Авторитетные авторы ScalaQuery, имеющие более 22 столбцов, несколько редки.
• Он чувствовал, что проекция этих таблиц, которые тянут более 22 колонок, еще реже.
• Typesafe работает над удалением 22 префикса из Tuples (и функций), и это необходимо для Scala, и как только это будет сделано, Slick больше не будет иметь проблем с 22 + таблицами столбцов. Поскольку проблема должна быть исправлена ​​в Scala, имеет смысл сделать это, чем создать новую ORM и работать с сообществом, чтобы принять ее.