API for creating relations

[CodeLionX]

Proposed Changes

• API for creating (should be typesafe)
  • Relation
  • Column
  • Records (Data Tuples, Rows)
• sample in-memory stores
  • RowRelation
  • ColumnRelation

Notes

• basic functionality working:

  • definition of columns (with type and name) and relations (with columns) working, see:

  val colFirstname: TypedColumnDef[String] = ColumnDef("Firstname")
  val colLastname: TypedColumnDef[String] = ColumnDef("Lastname")
  val colAge: TypedColumnDef[Int] = ColumnDef("Age")
  val R: ColumnRelation = ColumnRelation(Seq(colFirstname, colLastname, colAge))

  • two sample data stores: RowRelation and ColumnRelation, we should work on RowRelation as the logic there is way simpler
  • Functions in Relation:

  trait Relation {
  def columns: Seq[ColumnDef]
  def insert(record: Record): Unit
  def insertAll(records: Seq[Record]): Unit
  def where[T](f: (TypedColumnDef[T], T => Boolean)): Seq[Record]
  def whereAll(fs: Map[ColumnDef, Any => Boolean]): Seq[Record]
  def newRecord: RecordBuilder
  }

• example insert:

  R.insert(
  Record(R.columns) // Inits a `RecordBuilder` with the `ColumnDef`s to guarantee compatibility to `Relation`
    .withCellContent(colLastname -> "Maier") // value is type-checked
    .withCellContent(colFirstname -> "Hans")
  //    .withCellContent(colAge -> 33) // missing calls mean empty or (later) default value
    .build() // creates the `Record`
  )

• example where:

  /* explicit type-annotation allows using wildcard (`_`),
  * corresponding SQL:
  * SELECT * FROM $R WHERE "Firstname" == 'Hans';
  */
  R.where[String](colFirstname -> { _ == "Hans" })

Open ToDos (for separate PR!)

We must have a talk about these.

• key definition and primary key index
• column type annotations, eg. NotNullable, Nullable, defaults
• projection (SELECT)
• where-condition-builder to hide casting from application dev.
• functions using primary key to access the data
• multi-relation joins
• SchemaDef-trait ?? eg. Relation has a name, foreign-key constraints, ColumnDefs
• refactor: TypedColumnDef[T] --> ColumnDef[T] and ColumnDef --> UntypedColumnDef, because current TypedColumnDef[T] is used by application dev. and current ColumnDef should almost ever be hidden (used internally)

[CodeLionX]

I know that tests are missing! I will add them in a separate PR, together with some refactorings

[srfc]

Cool, I'm working on some tests right now but I can apply the changes to a new branch for the new PR.

[srfc]

W.r.t. the ToDo's - or talking points - you note for this PR:

• key definitions: I think we don't need to enforce a primary key on every relation. My thought process here is that, using the domain object model as described in the manifesto, I expect some relations to be very small or even single-row (see: Manifesto -> Customer -> Customer Info relation)
• I don't know how we should provide the interface for Nullable and NotNullable etc., but this will be a good functionality, albeit not of pressing necessity
• same goes for the where-condition-builder and multi-relation joins, I think
• I am very much in favour of refactoring the TypedColumnDef to be ColumnDef[T] and have an UntypedColumnDef since our current Relation impls don't support untyped ColumnDefs, right?

I also think we have focus on that relations are not tables in the model we're trying to implement. Well, they are, but they are not supposed to be used to, e.g. hold line items or large sets of data. So far we are, in fact, not planning on distributing relations on multiple actors, right?