2012-01-18 1 views
2

私はScalaを約6ヶ月使っていますが、Liftフレームワークに入っています。 Liftのドキュメントでは、デフォルトのMapperのものが提供されていますが、任意のORM(または類似のもの)を使用できます。リフトで代替ORMを使用して、任意の良い例は、(コメントのないソースはOKです)LiftのコンテキストでScalaQueryを使用する良い例は?

ありますか?私はScalaQueryを使用することに興味がありますが、提案は可能です。私の唯一の要件は、libがMSSQLをサポートしなければならないということです。私が見たことから、これはJTDS JDBCドライバを使用することに変わり、あなたはレースに出ます。

+0

私はあなたがしたいことを本当に理解していません。マッパーのツールとは異なるツールを使用してクエリを実行したいですか? –

+0

ほとんどの場合、@ChrisJamesCはい。どのような問題が起きるのか、関与するすべての動いている部分についての良い説明が存在するかどうか不思議だっただけです。下の答えは、私が探していたものです。申し訳ありませんが、あまりにもあいまいで特定の回答がありませんでした。 –

答えて

4

あなたはマッパー以外のリフトでORMを使用したい場合は、私がSquerylRecordをチェックアウトすることをお勧め。私は本当にScalaQuery ORMのではなく、SQLクエリのScalaのDSLを考えていないhttp://www.assembla.com/spaces/liftweb/wiki/Squeryl

:これは良い出発点でなければなりません。しかし、ORMが必要ない場合は、本当にいい選択です。また、スカラ統合クエリで行われている作業を確認してください:http://days2011.scala-lang.org/node/138/279。私はそれがまだ生産用の準備ができているとは思わない。

+1

FWIW、私は実際これに同意しません。 ScalaQueryはSquerylより優れています(IMO)。これは趣味の問題かもしれませんが、Liftでデータベースレイヤーを使用するために特別なものは必要ありません。 – timothy

+0

レコードはかなり壊れている/未完成のままなので、SquerylRecordを使用することでほとんど利益を得ることはできません。 Squerylは任意の制限があり、対処が非常に難しいデータベースに関するあらゆる種類の悪い前提を作ります。また、型の安全性を提供することもはるかに少なくなります。 ScalaQueryを使用して独自のモデルオブジェクトをローリングすることは、常にsquerylの限界に取り組もうとするよりもずっと簡単でした。 –

+0

私はそれぞれに小さな例をコーディングしましたが、私は同様の結論に達しました。私はScalaQueryの構文が気に入っており、DBとの会話をするのにはあまり魅力がないようです。 SquerylRecordは見て有益だった。 –

関連する問題