Docs on expected columns

[OscarGodson]

I was setting up a SQL database with model and it went fine for the most part, but there was some trial and error since there wasn't (or I might be missing it) docs on what columns are expected and what the types should be. The process for me ended up being something like the following. Each number was on each server restart as I went one by one:

1. Error: ER_NO_SUCH_TABLE: Table 'test.foos' doesn't exist - Oh create the table, model wont do this like the Mongo one (thats fine)
2. Error: ER_BAD_FIELD_ERROR: Unknown column 'id' in 'field list' - Oh create an id column (not uuid like I had)
3. Error: ER_BAD_FIELD_ERROR: Unknown column 'created_at' in 'field list' - Oh, create a created_at column (what format is this going to be in? datetime, timestamp, date...?)
4. Error: WARN_DATA_TRUNCATED: Data truncated for column 'id' at row 1 - Googles and figures out it happens when an ID is a string not a number on Stackoverflow. Alters table to change it to a VARCHAR(36)
5. Error: ER_BAD_FIELD_ERROR: Unknown column 'foos.updated_at' in 'field list' - Need to add that too to the table

Now, after those, I think I have everything. But it's not entirely clear. It'd be awesome to have just a general:

When using a SQL adapter your tables will need to be created manually. Each table should have an id, created_at, and updated_at column. The id column stores IDs in the format of UUIDs (so strings) and created_at and updated_at stores data in the format of datetime (YYYY-MM-DD HH:MM:SS)

I can send a PR too, but I wasn't sure if that information is right and is the same for all the SQL DBs.

[mde]

Part of this problem comes from the fact that within a Geddy app, you'd be using Migrations to set up all the tables/columns with a nice declarative API. (You could in theory use Migrations outside Geddy, but there's not a documented way to do it.)

Documenting all the datatype mappings would be good. Also good would be setting up a canonical way to use Migrations with Model in isolation, and documenting that.

At this point, an easy workaround would be to create a dummy Geddy app, and use the model generator (geddy gen model) to specify your properties and automatically great a migration you can run to create the table.

Let's start with a PR -- we should definitely have a small table with the mappings of JS datatype to SQL datatypes for each SQL adapter.