Database handling in graphback about graphback HOT 9 CLOSED

Really good discussion here. We need to get back to the updated idea of how database changes can be handled. Without bringing the tooling that can be used I think we need to think if we can
build state aware generation process.

Our project would have this state from previous generation, this will allow us to calculate diff and then see diff on the database to deliver sql statements. If we do that separately we can benefit from large set of the open source libraries that do database management right.

So TL:DR idea is to detach database management problem from graphql problem by collecting
schema changes and feeding them back to SQL Diff engine that can both apply changes directly or make migration scripts

from graphback.

Worth adding that template has generated folder that is dynamic:
Example:

|-----generated
       |-----schema.graphql
       |-----resolvers.ts
|-----model
       |-----<your-model-name>.graphql
|-----src
       |-----config
             |-----config.ts
       |-----db.ts
       |-----index.ts
       |-----mapping.ts
|-----package.json
|-----Dockerfile
|-----docker-compose.yml
|-----package-lock.json
|-----tslint.json
|-----README.md

Once the project is initialized users can possibly tweak all apart from the generated folder. We would really lose control over the rest of the stack and this can evolve towards production. Initial deployment to production can really base off development ddl model so migrate command is not essential to deliver complete workflow. Development, in this case, can be a wider term, but this is really about the fact that for localhost or any remote cluster desired we will automatically adjust database structure to work with the current schema/resolvers.

Couple questions based on the model:

• Where and how do you see the actual database running? Do we ignore that and assume that users will run docker-compose manually?

• How about the fact that we need to run this server after generation. How do you see people doing actual development?

With the latest release this will look like this:

1. Init project
2. Run docker compose with db
3. Generate resolvers
4. Generate DB
5. Run server manually

-- Now I want to edit something in graphql types.

6. Generate resolvers again
7. Drop database
8. Apply database schema
9. Start server again

It will be cool to have watch command that will look for modifications in types and perform steps from 3 to 9 automatically

from graphback.

watch command would be real nice feature. @wtrocki What do you think about templates for now as I have mentioned above?

from graphback.

Can you explain how you would see this working. Is all code editable or we will have runtime library that will setup db and it could be installed into vanilla templates?

It will probably require separate section to get into the idea. Whatever we go with there could be some side impacts and complexity related with aproach. We probably looking for something that is pluggable and also simple on its own

from graphback.

My approach would be to separate db specific templates and have a attribute that helps us choose config and docker-compose automatically for the template. If a user chooses a postgres template then we will inject postgres config and accordingly for different databases. The user can further edit these files according to usecases.

I added default configs in #56 , this will be modified going ahead when we add other templates and would be pluggable.

from graphback.

Agreed with everything. There is no need for follow up issue as we have all done

from graphback.

I think it will be worth to investigate prisma2 for this task to see how we can avoid writing this complex subsystem and do database migrations.

from graphback.

Let's leave it open and provide more details once we finish spikes

from graphback.

Content here outdated and we have couple separate issues. Closing this one

from graphback.