Zach Daniel

Alright, so my plan is to fix this after #255 and to make "fetch" style (where we look up the record by its primary key keyset and load any relevant...

Alright, I think perhaps this is all that is left to get https://github.com/ash-project/ash_graphql/pull/36 going?

🤔 I've just realized two things. 1. 64b3312 falls apart when there is no record with the provided primary key. I'm not sure if that is a kryptonite for that...

i.e flip `before` and `after` and say `limit: 1`. We can do that only on request via a pagination option, i.e `page: [populate_prev_page?: true]`, and then the graphql extension can...

I think for now, the relay specification required for `ash_graphql` allows for us to just say `false` when showing `hasNextPage` combined with `before` and `hasPrevPage` when combined with `after`, meaning...

Actually, this could be done differently. We don't need an `on_lookup: :unrelate` We just need to detect that the only thing we will do is look up records to unrelate...

Its a bit more complex behavior that way, but also gives users the optimization without them needing to care.

Looking at the code, I actually don't see any place that sets the default. So there is, in fact, *no* default value for `destination_field_on_join_table` and `source_field_on_join_table`. If anyone wants to...

We set these defaults now.

Actually...we don't :)