Hacker News new | past | comments | ask | show | jobs | submit login

Appreciate the candor, at least

  > "its errors are inconsistent enough to give you just enough constant false hope that your problem's fixed, but a second step is almost always needed.. and without a helpful error or button that just explains and fixes all the things from a single screen."
There are buttons on the "Settings" screen (/console/settings/metadata-status) you can click that should put your instance back in a working state (and it'll redirect you here by default if your metadata is invalid):

  > [DASHBOARD TEXT]: "You have been redirected because your GraphQL Engine metadata is in an inconsistent state. To delete all the inconsistent objects from the metadata, click the "Delete all" button. If you want to manage these objects on your own, please do so and click on the "Reload Metadata" button to check if the inconsistencies have been resolved."
As someone who still builds their personal projects with it -- yeah, the error messages can be kind of opaque if they're related to Hasura's internal metadata/state. For errors that come from external services, those are passed through at least when "HASURA_GRAPHQL_DEV_MODE" is enabled.

  > "It's unbearably fragile to state changes (eg, psql scripts + pg_dump/psql restores) ... I realize I'm probably using it wrong, but I really don't think I'm doing anything exceptionally "out there".
Are you dropping tables/columns which have metadata on them? IE, a relationship or permission on a table?

If you have metadata on a resource and then you remove it, without also removing references to it, the effect is the same as if you had tried to drop a table that has foreign keys that reference it in an RDBMS.




Thanks for the response! You're right that that's what I'm doing wrong, though the problem comes from after I recreate those relationships on the RDBMS side. Hasura really struggles to piece together that even though things were tore down, they were brought up in the same way. Having one button to "repair" it would be nice. This mostly happens because I more or less start from scratch on the RDBMS side every time I make a change. I'd do the same on the Hasura side, but tracking relationships (I think that's what it's called) takes about ten minutes to initialize on a relatively small database so I'm forced into making as few changes as possible.


  > "but tracking relationships (I think that's what it's called) takes about ten minutes to initialize on a relatively small database"
Oof, this is insane. Should not be the case.

Are you using the Hasura CLI to automatically track any changes made with the web UI to local YAML files? You can use this, along with the ".cli-migrations" variant of the Docker image to automatically apply your metadata/migration as soon as the image starts.

So you'd run "hasura console" in terminal, which would serve the special web UI that mirrors changes to local files, and that'll serve it on http://localhost:9695

Then when you want to start fresh, just docker-compose down/up and it'll handle auto-applying everything for you:

https://hasura.io/docs/latest/graphql/core/migrations/migrat...

https://hasura.io/docs/latest/graphql/core/migrations/advanc...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: