orm: add references attribute to allow foreign key declarations on fields

[asvln]

I have implemented a [references] attribute which allows foreign key creation on a field/column.

[table: 'thing']
struct Thing {
  id int [primary; sql: serial]
  color_id: int [references]
}

[table: 'color']
struct Color {
  id int [primary; sql: serial]
  hex string
}

[references] can be utilized in the following ways:

struct Thing {
  color_id int [references] // implicit table name and 'id' field
  color_id int [references: 'color'] // implicit 'id' field
  color_id int [references: 'color(id)'] // explicit
}

It utilizes the REFERENCES keyword on field declarations during table creation. I have only tested with sqlite3, but this sql syntax is supported on all current versions of sqlite3, mariadb, and postgres.

This only changes the generated sql, and is not something that v's orm can test directly so I have not added any tests.

[spytheman]

Sorry, but I do not know what it is supposed to do.

Can you link to some documentation of its expected behavior?

Can it be tested, by issuing direct SQL queries for a specific db (db.sqlite may be easiest, since it is more or less self contained, and supports ephemeral :memory: dbs), at least by retrieving the schema from an SQLite db, after a table with that attribute is created, but preferably with some observable side effect/behavior rather than just a schema change?

[JalonSolov]

FOREIGN KEY is a table level constraint, while REFERENCES is a column level constraint.

https://www.w3schools.com/mysql/mysql_foreignkey.asp

https://dev.mysql.com/doc/refman/8.0/en/create-table-foreign-keys.html

https://www.mysqltutorial.org/mysql-foreign-key/

REFERENCES is basically a way to tell which column in the other table the FOREIGN KEY applies to.

[asvln]

Can it be tested, by issuing direct SQL queries for a specific db

I have found an sqlite pragma which checks for applied foreign key constraints declared by the REFERENCES keyword and have added the appropriate test.

@spytheman: As an additional note, this PR is currently the only way to actually declare foreign key constraints with the ORM. [fkey] does not write any constraints to the database and only covers 1:N relationships.