implement basic table-level constraints/validation

[jrevels]

The most basic of which is a primary key relationship. Note that we actually originally decided not to have constraints in Legolas simply because we figured spelling e.g. allunique(my_table.my_primary_key_column) was sufficient (and likewise for issubset to test foreign key relations), but given that this is already emerging as useful downstream functionality, I think we might as well just have fully generic versions supported by the package.

[jrevels]

ref other packages that facilitate key handling

• https://github.com/JuliaData/IndexedTables.jl
• https://github.com/invenia/KeyedFrames.jl
• https://github.com/mcabbott/AxisKeys.jl

[jrevels]

EDIT: note that this comment is out of date in a post-Legolas v0.5 world

---

FWIW, my plan here API-wise is for Legolas.validate to basically validate "as much stuff as it can" given the input, then expect the caller to ensure that the input is the "actual thing they want to validate." This approach seems intuitive + appropriately caller-driven to me.

So:

• Legolas.validate(table_schema::Tables.Schema, schema::Legolas.Schema) only validates the schema (already implemented)
• Legolas.validate(table, schema::Legolas.Schema) will actually validate the contents of table as much as possible against schema
• Legolas.validate(table) will actually validate that table contains an extractable Legolas.Schema, and then call Legolas.validate(table, schema::Legolas.Schema) (already implemented)

[jrevels]

wonder if there should be a separate notion of "check constraints" for schema authors to express besides just normal per-field RHS stuff.

could imagine extending the macro:

@row(name, 
     fields..., 
     @check begin
         ...
     end)

then the check constraints could be invoked as part of one of the validate blocks (as well as construction)

[jrevels]

I wonder how crazy it would be to add actual primary/foreign key relations to Legolas:

@row(name, 
     @primary(pkey::UUID), 
     @foreign(fkey, "other-schema@2"), 
     other_fields...,
     @check begin
         ...
     end)

we'd be entering full relational IDL territory...things could get wacky. We could try to be pretty restrictive on what's supported, though; for example, not supporting composite keys + forcing referenced foreign keys to be actual primary keys (not just candidate keys). we could expand this later if we wanted

[jrevels]

xref #69 for a solid sketch of what convenient record-level check constraints could look like in a post-Legolas-v0.5 world