Declaring composite keys for self documentation and fulfilling KeyedEntity’s contract

The most compelling reason to use composite key is to implement the KeyedEntity trait (and enable it’s functionality). It also has the advantage of documenting the fact that fields/columns form a composite key. Another benefit is that equality expressions can be shortened.

Consider the following example where CourseAssignment is a KeyedEntity[CompositeKey2[Long,Long]]

CourseAssignment.id is a unique identifier for a CourseAssignment. In this case id is what makes the class a KeyedEntity[CompositeKey2[Long,Long]]. A class can have any number of composite keys, a composite key is not necessarily a primary key.

• Important: Squeryl will create a uniqueness constraint on composite keys that form the id of a KeyedEntity[_]

• Important: a compositeKey cannot be a val it must be a def

A composite key can be used in any equality expression (x === y), against a
composite key or a tuple that is compatible, i.e. that has the same type parameters, ex.:

• CompositeKey3[String,Long,float] is compatible with Tuple3(String,Long,Float)

• CompositeKey2[Long,Int] is not compatible with Tuple2(Long,Long)

Note CompositeKeys cannot be used as binding expressions in relations (see : issue 25)