How to model an entity with many children in Sorm?

Question

I have a Workspace and Document entities, with the idea that a workspace can contain zero, one, or more documents. My first approach to model this was:

case class Workspace(name: String, documents: Seq[Document])

but this will not scale well since my workspaces may contain many documents. Fortunately, my business requirement allow me to treat workspaces and documents separately (in the sense that when I have a workspace, there is no reason or invariant that forces me to consider all documents contained in it).

Question: I am wondering: how would I model Workspace and Document in Sorm so that I have a link between the two but do not have to load all documents of a workspace? I imagine to have a Repository that would give me access to the documents of a workspace, with pagination support.)

case class Workspace(name: String)
case class Document(name: String, /* ... */)

trait WorkspaceRepository {
  def children(ws: Workspace, offset: Long, limit: Long)
}

Answer 1

Easy peasy! You define them unrelated:

case class Workspace ( name : String )
case class Document ( ... )

Then you choose a way you wish them to be linked. I see two.

Variant #1

case class WorkspaceDocuments 
  ( workspace : Workspace, documents : Seq[Document] )

And get all documents of a workspace like so:

Db.query[WorkspaceDocuments]
  .whereEqual("workspace", theWorkspace)
  .fetchOne()
  .map(_.documents)
  .getOrElse(Seq())

In this case it makes sense to specify the workspace property as unique in instance declaration:

... Instance (
  entities = Set() +
             Entity[WorkspaceDocuments]( unique = Set() + Seq("workspace") )
  ...
)

Variant #2

case class WorkspaceToDocument
  ( workspace : Workspace, document : Document )

And get documents of a workspace like so:

Db.query[WorkspaceToDocument]
  .whereEqual("workspace", theWorkspace)
  .whereEqual("document.name", "...") // ability to filter docs
  .fetch()
  .map(_.document)

First variant won't let you filter docs in your query (at least in SORM v0.3.*) but due to ability to set a unique constraint on a workspace it should perform better on workspace-based queries. The second variant is more flexible, allowing you to apply all kinds of filters.