問題タブ [slick-2.0]

実際、クラス名に関していくつか問題があります。ここに問題があります

私はこのようなケースクラスを持っています、

そしてSlickのプロジェクションクラス、

残念ながら、ケース クラス名 == オブジェクト

これは古いコードであり、ケース クラスとオブジェクトは多くの場所で使用されているため、ケース クラスまたはオブジェクトの名前を変更することはできません。それらは同じ名前であるため、プロジェクション クラスの作成に問題があります。次の行でエラーが発生します。

そして、ケースクラス名を変更してそれをプロジェクションクラスで使用すると、正しく動作しますが、ケースクラスとオブジェクトが同じ名前であるため、この問題が発生しています。この問題の解決策はありますか? ケース クラス/オブジェクト名を変更せずに解決できますか??

多数の小さな列と大きな (たとえば BLOB) 列を含むテーブルがあるとします。

状況によっては、列を除くすべての列についてテーブルをクエリしたいと思いlargeます。他にも、入れたいと思います。タプルよりもケースクラスを使用することを好みます。

これを行うためのSlickに良いパターンはありますか?

私が検討したオプション：

1. 「スキニー」マッピングと「ファット」マッピングの 2 つのマッピングがあります。
2. 大きな列を別のテーブルに分割し、必要に応じて結合します。

次のコードでは、レコードを問題なく挿入できます。しかし、挿入された値の ID を取得して、応答の一部としてオブジェクトを返すことができるようにしたいと考えています。

そこで、挿入を次のように変更してみました。

しかし、次の例外が発生します。

ここにメモがあります：http://slick.typesafe.com/doc/2.1.0/queries.html

「多くのデータベースシステムでは、テーブルの自動インクリメント主キーでなければならない単一の列のみを返すことができることに注意してください。他の列を要求すると、実行時に SlickException がスローされます (データベースが実際にサポートしていない場合)。」

ただし、ID 列を要求する方法については述べていません。

モデルケースクラスで java.util.Date を使用しています。Slick はすぐに使用できる juDate をサポートしていないためimplicit val dateColumnMapper = MappedColumnType.base[Date, SqlDate](d => new SqlDate(d.getTime), d => d)、テーブル クラスにそのような暗黙的なマッピングを追加しました。

しかし、今は日付フィールドによるフィルタリングにこだわっています: proposalsQuery.filter(_.since >= since). さまざまなオプションを試しましたが、常にコンパイル エラーが発生します。value >= is not a member of scala.slick.lifted.Column[java.util.Date]

私はScala/Slickの作業例が初めてなので、問題を簡単に説明していただければ幸いです。

ありがとう！

Slick 2.1.0 と PostgreSQL 9.x を使用しています。

Slickの持ち上げられたクエリを使用して、このSQL（postgresqlに正しい）を作成するにはどうすればよいですか：

このコードは機能しません (シンボル 'in' を解決できません):

実際、slick を使用して MySQL DB に DateTime 値を格納する際に問題が発生しています。次のようなケース クラスがあります。

そして、その滑らかな射影クラス:

データを挿入しようとすると、「America/New_York」のタイムゾーンを定義したときに、MySQL テーブルの結果の日付に UTC タイムゾーンのタイムスタンプが表示されます

日付が EST タイムゾーンではなく UTC タイムゾーンで保存されるのはなぜですか

Scala は Java のボイラープレート プラクティス (およびそれ以前の不変性、ファースト クラス関数型プログラミングなど) を解きほぐすことに着手しましたが、洗練されたライブラリ チュートリアルでは、単純なテーブル定義に関する多くのボイラープレートが提案されています。

この API の使用例は、慣用句に近いとは言えません。テーブル名、列タイプ、列名について、上記の派生作業コードのすべての重複を列挙するのは簡単です。このスタイルを使用して、私のコード ベースに優雅さを備えた大規模なスキーマを定義することを想像するのは難しいと思います。

これらすべての重複と冗長性が不要になるように、これを削減するお気に入りの方法は何ですか? 洗練されたコード生成が唯一の解毒剤ですか?

私はこれを見つけましたが、ライブラリ作成者のマインドダンプに飛び込むよりも、アプリケーションロジックに集中することを本当に好む場合があります。彼らの貢献は寛大です. 誤解しないでほしいのですが、slick はとてもクールだと思います。ただ、この量のボイラープレートは単純な例であり、何らかの方法で大幅に単純化できるはずです...