Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to use with explicit many-to-many models (error in Edit view due to Input) #32

Open
bennettrogers opened this issue Aug 21, 2020 · 8 comments

Comments

@bennettrogers
Copy link

My schema has a few models that are related via many-to-many relations. I'm using the explicit form of the relation in my prisma schema by defining the intermediate model exactly as described in the prisma docs.

As requested in the docs for ra-data-prisma, I'm calling addCrudResolvers on all 3 models (both sides of the relation and the intermediate model).

On the frontend, I'm also defining resources for all 3 models. My issues start when trying to build out the Edit page for the intermediate model. The List view works fine, but when trying to show the Edit view I'm getting a graphql error that says Error: Variable "$where" got invalid value "MODEL_ID" at "where.id"; Expected type StringFilter to be an object. This happens with both the EditGuesser and when trying to define a basic SimpleForm with only a single TextField for the id. (MODEL_ID actually shows up as the string id of the instance it's trying to fetch).

It seems that the Input type expected in the Edit view for the intermediate model is different from the Input type expected by other Edit views, including those for my one-to-many relations. The intermediate model is looking for a ${typeName}WhereInput, whereas the other models are looking for a ${typeName}WhereUniqueInput. This is causing the error since the dataProvider is passing just the id for both Inputs, but ${typeName}WhereInput seems to want a StringFilter.

Sorry for the long explanation. I'm not even sure this is the right package to be creating the issue for. If the explanation isn't clear, I'd be happy to try to create a minimal test repo that demonstrates the issue.

Thank you again for your help.

@bennettrogers
Copy link
Author

And as is so often the case, after hours of debugging I find the issue right after submitting the github issue.

It seems that the problem stems from the way Prisma recommends naming intermediate many-to-many models. If the related models are Post and Category, the recommendation is to name the intermediate model CategoriesOnPosts. Then in the backend package for ra-data-prisma, the queryAllName is auto-generated using the pluralize package. But when pluralize runs on a model name like CategoriesOnPosts, the result is ... CategoriesOnPosts! So the queryAllName clobbers the queryName, resulting in no available query for a singular object, and a graphql endpoint that thinks the Edit view is asking for many objects when it's only asking for a singular object.

I can get around this by changing the name of my model. Now that I know what's causing it, I'm wondering what the right solution is though. It seems like perhaps queryAllName should be guaranteed to be different from queryName, even if queryName is plural by default?

The challenge of "naming things" strikes again...

@macrozone
Copy link
Member

macrozone commented Aug 21, 2020

And as is so often the case, after hours of debugging I find the issue right after submitting the github issue.

haha, story of my life.

But when pluralize runs on a model name like CategoriesOnPosts, the result is ... CategoriesOnPosts! So the queryAllName clobbers the queryName, resulting in no available query for a singular object, and a graphql endpoint that thinks the Edit view is asking for many objects when it's only asking for a singular object.

So it should be CategoriesOnPostss ? with two s? I think that should be an easy fix.

Edit: we should use the same pluralization that prisma uses, thats currently not the case.

@bennettrogers
Copy link
Author

The example I linked to in the Relation docs does use CategoriesOnPosts as the intermediate model name, but the "Conventions for relation tables" documentation uses a different convention. It indicates that Prisma itself uses _CategoryToPost, which would avoid the pluralization problem in most cases. I will switch to using something closer to that.

Even so, regardless of what pluralization strategy ra-data-prisma uses (and pluralize seems like a great option), it seems like maybe there should be some kind of guarantee that the different query (and mutation) names will not conflict. For example, if I named one of my primary models Categories, I think I'd run into the same problem.

ra-data-prisma uses ${pluralize(queryName)}Count for the queryCountName... what if it just did something similar for the queryAllName - ${pluralize(queryName)}All? Or ${pluralize(queryName)}Many to align with the mutation names?

@macrozone
Copy link
Member

@bennettrogers the problem is, that nexus-plugin-prisma defines these plurals already:

// given model "User"

// nexus-plugin-prisma now defines

t.crud.user 
t.crud.users

So our pluralizing function should do the same as they do. Probably we could just append a s when plural name after pluralize is the same as singular name. Did not yet had time to look into the code of nexus-plugin-primsa yet though

@bennettrogers
Copy link
Author

It looks like they're struggling with a similar issue:
graphql-nexus/nexus-plugin-prisma#537

The most recent comment on that issue sounds reasonable to me: nexus-plugin-prisma and ra-data-prisma could just copy what Prisma2 has started doing (appending findOne(), findMany(), etc to the model names).

@macrozone
Copy link
Member

@bennettrogers so we need to wait until that is resolved in nexus-plugin-prisma

@bennettrogers
Copy link
Author

Yes, exactly! Sorry, that's what I should have said.

@macrozone
Copy link
Member

upstream PR is open, not sure if it will be merged soon graphql-nexus/nexus-plugin-prisma#804

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants