playframework-2.0 - SLICK と 22 列制限のある Playframework

Question

私は Play フレームワークの評価と Scala の学習を行っていますが、これは楽しいものです。Java から Scala への移行にはかなりの精神的体操が必要でしたが、今ではそのファンです。

私はすでに JPA を使用してマッピングされたかなりのデータベースを持っており、このコードを (休止状態で) 引き続き使用するつもりでしたが、これは Scala での最適または推奨されるアプローチではありません。そこで、SLICK を使用していくつかのテーブルのマッピングを開始しましたが、先に進む前に、ケース クラスと関数パラメーター (最大 22) に関する Scala の制限に問題が発生することに気付きました。

現代のORMにこの制限があることは、完全に困惑しています。Scala にこの制限があることに問題はありません。結局のところ、関数に 22 個のパラメーターを渡したいのです。だから私の質問は、なぜこの制限でライブラリを設計するのですか? 確かに、通常のクラスにマップするように設計されているはずですか? 仕事を成し遂げるためにリフレクションを使用したとしても、私は気にしません。

ケースクラスを分割し、暗黙的な変換を使用して再結合する必要がある、これに対する回避策を見てきました。しかし、これは単なるハックです。

Play を使い続けたい場合は、Java に切り替えて JPA を使用する必要があると思います。

Answer 1

この奇妙に番号付けされた制限は、Scala プログラミング言語がタプルの最大サイズを 22 に制限しており、タプルがテーブルの行を表す優れた方法であるためである可能性が最も高いです。scala 関数が 22 個のパラメーターに制限されているのはなぜですか? を参照してください。詳細については。Scala 2.11 (およびおそらく Slick) でこの制限を削除するという話がいくつかあり、それを追跡する未解決の問題がありますが、最近の 2.11 リリースの時点では、これは発生していません。

私は Slick 開発者ではありません。Tuples の代わりに List のような制限のないものに基づいて ORM を作成できたと確信しています。なぜそのような結果になったのかについての私の仮説は次のとおりです。

• Typesafe は ORM をゼロから構築したくなかったので、最も安定して広く採用されている scala 用の ORM パッケージの 1 つである ScalaQuery から Slick を採用しました。
• ScalaQuery の作成者は、設計の重要な部分としてタプルを使用することが適していると考えました。
• ScalaQuery の作成者は、22 列を超えるテーブルはやや珍しいと感じました。
• 彼は、22 列を超えるテーブルのプロジェクションはさらに珍しいと感じました。
• タイプセーフは、タプル (および関数) から 22 の制限を取り除く方向に取り組んでおり、これを行うことは Scala に必要であり、これが完了すると、Slick は 22 列以上のテーブルで問題を抱えることはなくなります。この問題は Scala で修正する必要があるため、新しい ORM を作成してコミュニティと協力して採用するよりも、これを行う方が理にかなっています。