SORMの力を発揮する絶好の機会です。
SORM の機能に示されているように、SORM はすべてのリレーショナル概念から抽象化されています。これには外部キーが含まれます。
外部キーの抽象化は、外部キーで参照したかったこれらのエンティティへの自然な直接参照によって提供されます。したがって、 of を指す代わりに、userId
プロパティを使用してそれ自体を指す必要があります。id
User
User
user
case class User(login: String, firstName: String, lastName: String)
case class UserSite(user: User, name: String, url: String)
内部的には、これは外部キーで達成したいことと正確に一致します。しかし、問題は、それを気にする必要がないということです。
余談。SORM を使用する場合は、Scala で使用したい方法でモデルをほとんど制限なく設計する必要があります。また、モデルを設計するときに慣れ親しんだすべてのリレーショナルの概念を完全に忘れる必要があります。それがSORMのやり方です。
ドキュメントとライブラリ構造について。アプローチは非常に単純です。文書化されていない場合、パブリック API の一部として使用することは意図されていません。0.3.x
また、SORMの現在の (v. ) 構造では、パブリック API のすべてのコンポーネントがsorm._
パッケージに存在するため、別のルールは、そこにない場合、パブリック API を意図していません。