Add support for single record queries by primary key

[spitfire55]

What kind of change does this PR introduce?

Users can now use [table_name]ByPk(key) queries to get a single record using the primary key

What is the current behavior?

No first-party support for single record queries by primary key.

See #554 .

What is the new behavior?

Adds a [table_name]ByPk(pk: pk_type) method to all tables that define a primary key

[imor]

Hey @spitfire55 , thanks for this PR. We haven't forgotten this, just totally slammed right now. Will come back to it eventually.

@olirice before we review this, do you an opinion on the approach here. Do we want to add a method to access object by pk as implemented in this PR?

[olirice]

yes, i think there's been enough demand for it to justify the addition + it doesn't introduce any performance issues

Like Raminder mentioned, we're pretty slammed right now so it may take some time to work through this and review so sorry in advance for that!

From a very quick glance the things that jumped out are

• lets filter the entities that automatically get these entrypoints to those that have primary keys of a type that's in a whitelist -> int, bigint, uuid, string are the ones that make sense to me
• use exhaustive pattern matching where possible so its easier to find what needs updating when we extend enums in the future

appreciate your work on this, looking forward to getting it merged

[spitfire55]

@imor @olirice any chance this can get reviewed and merged this week?

[imor]

@spitfire55 I'll find some time today or tomorrow to review it. Sorry for the delay and thanks again for your patience.

[imor]

LGTM apart from missing docs. @olirice would you like to take a look?

[olirice]

@imor conceptually I'm on board

but there are several untested pathes. The biggest ones are:

• nodeByPk with a nested function ref
• nodeByPk with a connection ref
• introspection including __typename ref
• selecting an unknown field ref

If

• we can resolve the coverage issues ^ + not have this PR decrease coverage
• you've reviewed the code, are happy with it
• its been tested in GraphiQL manually to make there are no errors and looks as expected with a few sample tables
• docs

then we'll be good to go

[imor]

@spitfire55 would you mind making changes suggested by @olirice.

[spitfire55]

Yep, I'll tackle these this week.

[spitfire55]

@imor after months of neglect, I've updated this PR to get code coverage back to where it should be. Hopefully can be merged.

[imor]

Thanks for you hard work on this @spitfire55. I'll review this.

[imor]

Hey @spitfire55,

I've reviewed the code and it is 99% there. I've also tested in GraphiQL with a complex schema and data and everything works.

I've left some minor comments to be tackled. There's a comprehensive test case coverage but imo we can add following test cases to cover a few more edge cases:

• Tables without a primary key shouldn't have a <table>ByPk exposed in the query.
• Test that aliases work correctly with <table>ByPk fields.
• Test that only supported column types have a <table>ByPk fields exposed and other types don't

Apart from above if docs/api.md and docs/changelog.md files could be updated to mention the change with examples, this PR should be ready to merge.

[spitfire55]

Addressed everything above. If the UUID --> Uuid rename should be split out to a separate PR, I can do that.

[imor]

Thanks again Dale, I'm going to merge this. I'll add docs in a separate PR.

[imor]

@olirice need your approval to merge since you requested changes.

[imor]

Draft PR for docs here: #624