Output information on PRIMARY KEY and UNIQUE constraints

[frankpf]

This PR implements part of #77. It modifies schemats so it outputs interfaces like this:

interface usersMeta {
   id: { type: string, primaryKey: true, unique: false },
   email: { type: string, primaryKey: false, unique: true }
}

It also adds the --verbose flag to control the output. When verbose mode is on, the meta-interfaces are simply renamed:

export type users = usersMeta

If it's off, the meta-interfaces are simplified using the helper types in #77 (comment):

export type users = SimpleSchema<usersMeta>

One thing to note is that the non-formatted output includes some trailing commas. I couldn't test the formatted output because I was getting the following error from 'typescript-formatter:

TypeError: ts.formatting.RulesProvider is not a constructor
    at getRuleProvider (/home/frank/Code/schemats/node_modules/typescript-formatter/lib/formatter.js:18:28)
    at Object.format [as default] (/home/frank/Code/schemats/node_modules/typescript-formatter/lib/formatter.js:12:58)
    at /home/frank/Code/schemats/node_modules/typescript-formatter/lib/index.js:110:48
    at <anonymous>

[xiamx]

Would it be better to change the name of "verbose" parameter into something more descriptive for example "extendedTableMeta" ?

[xiamx]

Looks like the RuleProvider error is being fixed by #82

[frankpf]

I updated the flag to be --exposeConstraintInfo, as that does not require the user to understand what the "meta-interfaces" are. What do you think?

[frankpf]

The tests/examples/README still need to be updated, I'll try to do that this week.

[abenhamdine]

Good work !
--exposeConstraintInfo sounds ok to me.
Concerning my comment #77 (comment), if you plan to add comments and original sql types in output : on second thougth, I think they should always be included in non verbose mode, because they are convenient for any user.
But it' just my opinion.

[frankpf]

I tested adding the original SQL type to the output ({..., originalType: 'text' }).

The reason I didn't include it in this PR is that some types (at least in Postgres) are mapped internally to something else. For example, a column with a char type will be mapped to bpchar internally. The output would be originalType: 'bpchar'. IIRC there's a way to get the actual char type from Postgres, but it's a bit more involved.

I don't know if that's a big problem though. Maybe we should add it with those internal Postgres types now and then try fix the library to use more "specific" types later?

[abenhamdine]

some types (at least in Postgres) are mapped internally to something else. For example, a column with a char type will be mapped to bpchar internally. The output would be originalType: 'bpchar'

IIRC, for most of the types, udt name is pretty clear.

Anyway, I think it's better for this PR to focus on constraints only.

[abenhamdine]

I don't know if that's a big problem though. Maybe we should add it with those internal Postgres types now and then try fix the library to use more "specific" types later?

Seems reasonable.

[frankpf]

All tests are passing 😃

[DiskImage]

Is this totally dead? I was really hoping schemats supported exporting unique/pk constraints to aid in type safe upserts!

[xiamx]

Both of the original maintainers @crispmark and I left sweetiq and to the best of my knowledge there's no one maintaining this project at the moment.

[frankpf]

@DiskImage Last time I ran it, this PR was working fine. It's not in master but if you really want this you can clone the branch and use it. I can help you if you have any issues with it.

I'm working on a new project using http://www.pg-structure.com/ to do the same thing here. The difference to schemats is that pg-structure creates a data structure to introspect the database, so you can use it to create all kinds of outputs, whereas schemats is "hardcoded" to output TypeScript interfaces.