Fixing schema data types and database types

[subnetmarco]

Addressing this issue: bb12c81#commitcomment-10298943

I am not happy because it introduces one more property in the schemas. In the early days we tried to fix this with convention but it didn't work out well because of edge-cases, but maybe we can stil try going through that path.

To recap before we tried to fix this problem with convention and we tried to get everything that ended with *id and treat it as an UUID. This didn't always work well because some properties, like accounts.provider_id, are not UUIDs but custom strings.

So we decided to make id and timestamp data types, but they really are string and number. We have three options here:

• Fixing the convention problem, but it's not going to be scalable in the future
• Extending the types and make the implicit assumption that id is always going to be string and timestamp is always going to be a number.
• Introducing represents or something like that.

[coveralls]

Coverage increased (+0.17%) to 72.48% when pulling 20deb99 on fix/schemas into d5ce9dd on master.

[coveralls]

Coverage increased (+0.17%) to 72.48% when pulling 20deb99 on fix/schemas into d5ce9dd on master.

[subnetmarco]

I decided to remove represents and make the database types actual data types.

In the schema validation id is an alias for string, and timestamp is an alias for number.

[subnetmarco]

This pull request also fixes #81

[coveralls]

Coverage increased (+0.22%) to 72.53% when pulling 11e97ac on fix/schemas into d5ce9dd on master.