feat: Enable customization through a relationship filter #70
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I had originally opened an issue, but thought it would be better to POC the change I was hoping for and see if this is something worth getting into the main branch.
The problem
We would like to use the pg-many-to-many plugin to enable relationships between linker tables. While the plugin does work for this, it also ends up creating a lot of relationships based on constraints across all the tables we have which result in very verbose resolver names, such as
entityByEntityAIdAndEntityBIdAndEntityCId
, etc.The
@omit manyToMany
option does allow us to remove these resolvers, but because its opt-out first, we are having to do this on most constraints and it makes the growing schema difficult to manage, as it becomes a requirement that we can't forget to do.Proposal
Allow consumers to pass a filter function that can let them decide when the derived relationship should result in a valid
manyToMany
connection. This function, here calledpgManyToManyFilter
, is backwards compatible and opt-in, so it has no downstream effects on existing usages.An example of the usage, in the case of only wanting to enable for relationships where the linker table has a composite primary key, would look like:
I did not add any tests to validate this proposal, as I wasn't sure if it would be accepted as is, but I'd be happy to do so. We are currently consuming my fork, but I would prefer to get this change (or something similar) into the primary repo so we can point back to it.
Thanks again for contributing to OSS!