Graphback: [graphback db] migrations should only generate tables for types annotated with `@model`

[craicoverflow]

[wtrocki]

To make graphql-migrations work with any upstream we can use filter feature ->

https://github.com/aerogear/graphback/blob/master/packages/graphback-cli/src/components/db.ts#L43-L46

We should change the filter to support arrays or simply filter out schema before passing it to db migrations.

This clashes with the idea of having models relationships to non models. Database migrations will need to understand this complex situation

[NomadXD]

@wtrocki @craicoverflow Can I work on this issue ?

[wtrocki]

Go ahead. Check packages/graphql-migrations

[craicoverflow]

You will find that at the minute graphql-migrations does this with isModelType here.

We left this open because our plan was to make this an option in migrateDB so users only use it if they wished.

Here is a commented out snippet of what this would look like:
https://github.com/aerogear/graphback/blob/master/packages/graphql-migrations/src/migrate.ts#L112

[NomadXD]

Okay so what I have to do is implement another filter like _removeNonSafeOperationsFilter_ and use that filter before calling the _generateAbstractDatabase_ method. So users can add the filter in migrateOptions in their runtime.ts file. Right ?

[craicoverflow]

Exactly! This will make it customisable.

Tip: GraphQL schemas are immutable so you will need to use graphql-compose

[NomadXD]

Okay thanks. Will ping you back if I get across any issues or clarifications.

[craicoverflow]

Hi @NomadXD any update on this one?

[lastmjs]

So has the graphback db command been removed as of alpha 4? Is the only way to do migrations to use the programmatic graphql-migrations api?

[wtrocki]

Yes. Since we want to support custom scalars this was the only way and since we use only db for postgress it was confusing (Mongo do not have it)

[craicoverflow]

Going to close this as we have added a check in graphql-migrations to only create @model annotated tables.