apollo-fullstack-react-postgres-ts template project error about graphback HOT 12 CLOSED

@RinkiyaKeDad problem is related to the UI/client application - server will work fine.

Client app uses schema and generates queries. Etc.

from graphback.

@RinkiyaKeDad , yes you need to make some minor fixes in the client. Changing from _id to id.
client/src/components/notes/
client/src/components/comments/
etc
The console will tell you.

You also should not rely on trying to get auto-migration working with the primary key changing. Blow the db away and start again. Much easier.

I could upload my changes @wtrocki ? Should i issue a pull ?

from graphback.

How about using the same client but replacing instances of _id with an environment variable and we'll provide a different .env file for mongodb and postgres? That way we won't have to maintain two clients.

This won't work as environment variables cannot be used inside a GraphQL schema file.

What could work for this is adding a @autoIncrements annotation to Graphback which is a way to explicitly say this field should be an auto-incrementing field.

Although I feel that this is us treating a symptom of the design instead of a solution.

Have a think about other ideas and feel free to share them here so we can discuss @RinkiyaKeDad :)

from graphback.

I though I left comment here. Issue is that we use single client app for mongo and postgress. For mongo we use more specialized scalar for data and it looks like package bump introduced some coupling. Fix is needed

from graphback.

Modifying the schema to use "id: ID!" and regenerating fixes the issue.

Do you mean the datamodel? Cause I changed _id to id in the datamodel and starting the server after running yarn generate gave me this error:

npm run develop

> [email protected] develop /home/arsh/PracticeProjects/postgres-test/postgres-test-2
> ts-node src/index.ts

🚀  Server ready at http://localhost:4000/graphql
(node:44594) UnhandledPromiseRejectionWarning: error: ALTER TABLE "public"."note" DROP CONSTRAINT "note_pkey" - cannot drop constraint note_pkey on table note because other objects depend on it
    at Parser.parseErrorMessage (/home/arsh/PracticeProjects/postgres-test/postgres-test-2/node_modules/pg-protocol/src/parser.ts:357:11)
    at Parser.handlePacket (/home/arsh/PracticeProjects/postgres-test/postgres-test-2/node_modules/pg-protocol/src/parser.ts:186:21)
    at Parser.parse (/home/arsh/PracticeProjects/postgres-test/postgres-test-2/node_modules/pg-protocol/src/parser.ts:101:30)
    at Socket.<anonymous> (/home/arsh/PracticeProjects/postgres-test/postgres-test-2/node_modules/pg-protocol/src/index.ts:7:48)
    at Socket.emit (events.js:314:20)
    at Socket.EventEmitter.emit (domain.js:483:12)
    at addChunk (_stream_readable.js:297:12)
    at readableAddChunk (_stream_readable.js:272:9)
    at Socket.Readable.push (_stream_readable.js:213:10)
    at TCP.onStreamRead (internal/stream_base_commons.js:188:23)
(node:44594) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:44594) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
(node:44594) UnhandledPromiseRejectionWarning: error: alter table "public"."comment" drop constraint "comment_noteid_foreign" - current transaction is aborted, commands ignored until end of transaction block
    at Parser.parseErrorMessage (/home/arsh/PracticeProjects/postgres-test/postgres-test-2/node_modules/pg-protocol/src/parser.ts:357:11)
    at Parser.handlePacket (/home/arsh/PracticeProjects/postgres-test/postgres-test-2/node_modules/pg-protocol/src/parser.ts:186:21)
    at Parser.parse (/home/arsh/PracticeProjects/postgres-test/postgres-test-2/node_modules/pg-protocol/src/parser.ts:101:30)
    at Socket.<anonymous> (/home/arsh/PracticeProjects/postgres-test/postgres-test-2/node_modules/pg-protocol/src/index.ts:7:48)
    at Socket.emit (events.js:314:20)
    at Socket.EventEmitter.emit (domain.js:483:12)
    at addChunk (_stream_readable.js:297:12)
    at readableAddChunk (_stream_readable.js:272:9)
    at Socket.Readable.push (_stream_readable.js:213:10)
    at TCP.onStreamRead (internal/stream_base_commons.js:188:23)
(node:44594) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 4)
^C

This means simply changing _id to id in the datamodel for the postgres template would not work. Also creating notes works when done using graphql playground so I guess something needs to be changed in the client template right @wtrocki?

from graphback.

I got little bit confused so I would really appreciate PullRequest

from graphback.

@RinkiyaKeDad problem is related to the UI/client application - server will work fine.

So should I replace _id with id in the client template? But that would make it stop working with MongoDB no?

from graphback.

The same client is used in mongodb and postgress backend. Thus _id is needed.
This might be confusing for postgres devs who use id but that is just example app limitation - developers can use any schema they want. We still wanted to keep some client APP but I would also think if there is value in maintaining this considering it put some requirements to keep the same schema and it will break if schema is changed even slightly.

CC @craicoverflow WDYT?

from graphback.

What about having two separate client templates based on the database? We would just need to replace _id in one and then none should break regardless of schema changes.

from graphback.

My thought was also to have 2 separate clients. The problem with that is it multiples the maintenance burden. Both clients will be exactly the same except for the ID, so both will need to be kept in sync manually.

from graphback.

How about using the same client but replacing instances of _id with an environment variable and we'll provide a different .env file for mongodb and postgres? That way we won't have to maintain two clients.

from graphback.

After discussion on discord we've decided to have the client app working with postgres only (and not mongo) since we will still have client-side queries for testing. Will be raising a PR for the same.

from graphback.