Closed Ked57 closed 4 years ago
What is the performance impact of going through the view instead of hitting the table directly?
I'm not sure how to measure it but it's fast in local testing (which might not be relevant), I haven't experienced any regression.
I'm surprised that the Hasura metadata is in a new file. There should be existing metadata, right? I'm surprised to find `metadata.yaml` in the `migrations` folder. Could you back that decision with Hasura documentation?
This repo is still using the version 1.0.0 of Hasura so it makes sense that there is a metadata file. What doesn't make sense is that there is two, according to https://hasura.io/docs/1.0/graphql/manual/migrations/config-v1/reference/metadata-file-format.html#metadata-file-format-v1
my CLI is in version 1.2.2 so that might be the problem since they changed the migration process in 1.2 and I used the CLI to run hasura console
. It looks like the yaml and the json are the same
I just tried doing hasura migrate apply
on a clean install and it works, I tried deleting the metadata.json
file and it works, all the permission are here. The JSON file might be junk from before we used migrations
But is the metadata file useful since pre-1.2 the migrations includes metadata changes?
Right now, in the current configuration, it is mandatory. But we will have to upgrade to the new config standard: https://hasura.io/docs/1.0/graphql/manual/migrations/upgrade-v2.html
see #58
resumes are versionned using the version_date field, this field was added to the primary keys to make sure we get only one version per day. On update the data is upserted so it's either updated if there is already a resume in the database for the
version_date
of the insertion, or inserted if not.I created a view to only get the last version of a particular resume, then adapted the backend code to use the view
I tested it by using 3 different versions of my resume and having another resume to make sure I had both in lists. Listing, editing and viewing all seem to work as expected