Nexus-plugin-prisma: Option to Disable and Collapse Atomic Operations

[hatchli]

This issue raised with the Prisma team was initiated by ~2.6's introduction of Atomic Operations. As you can see there, I ran into the issue that "set" was now required with every update/upsert performed on strings/ints/floats - a breaking change. I initially believed this was a bug resolved by the 2.6.2 hotfix, however @jasonkuhrt clarified what was in fact happening:

Hey @pantharshit00, @hatchli; This does not represent a bug in the Nexus Prisma plugin but a limitation with the GraphQL specification which does not support unions in input types (it is coming eventually).

Nexus Prisma _could_ have a feature that allows you to disable this Prisma feature and "collapse" the atomic operations back to string at the GraphQL schema level where a string would infer a set (could be configurable too).

Nexus Prisma _could_ also eventually have rich mapping features that permit ad-hoc customization of how the GraphQL schema maps to the Prisma Client API.

But as it stands today, if you want to upgrade, you're going to _have_ to do exactly this:

go back adding "set" to every single update/upsert field if it's unnecessary.

You are more than welcome to make a feature request about how you wish the crud system worked instead.

I am hoping that Atomic Operations would be configurable, much in the way CRUD or pagination are currently configurable in nexus-plugin-prisma.

[homerjam]

Any pointers for contributing a fix or any workarounds for this? I think I vaguely understand the what/why but it's kind of a bummer. I gather a fix would need to modify/filter the dmmf??

[alexvilchis]

I need this! Now I have to update nearly 50+ mutations

[hatchli]

@alexvilchis I have downgraded to 17.0 and used yarn resolutions to force the older Prisma.

I recommend this for everyone now until the nexus-plugin-prisma team sorts this (or @homerjam is able to figure it out!).

[homerjam]

After some serious rooting around (the Nexus ecosystem is pretty sophisticated and a bit tough for me to grasp) I think it's potentially quite a big ask to implement what might be a temporary workaround. I view this plugin's role as providing a quick and easy integration of Prisma's core methods into your code-first Nexus API. It's doing that already.

In the end I was able to write a simple helper to wrap my existing update* input payloads in order to use the latest versions. Although it seems like an unnecessary extra step and a pain to update existing code I believe in the long run the ideal solution is to wait for GraphQL to support unions in input types - this will enable the plugin to most accurately reflect Prisma's API. As opposed to making an already complex codebase even more complex!

[hatchli]

Is it the nexus-prisma-plugin team's plan to simply wait for unions in inputs?

This is really going to be unfortunate to have to sit out of all future prisma releases.

[jshimko]

Forgive my unfamiliarity with this code, but is there any reason we can't default to the previous behavior for input types (as in no atomic operations inputs, just the value to set for the field). I suspect that scenario is _way_ more common for everyone. And having to explicitly do: field: { set: value } for _every_ updated field is super tedious and verbose. I'd much rather not have atomic operations stuff on the client side than have to refactor all of my client side inputs for something I rarely use (compared to just setting a value). And even if I really needed atomic operations, I could write a custom resolver on the server side to use that feature.

Perhaps just a configuration option as a short term solution so we don't have to choose between staying on Prisma 1.5.1 or refactoring a bunch of client side code? Not sure how painful that is to implement, but I suspect a lot of people would prefer that option over waiting for the GraphQL spec to change.

Happy to help if there's something I can do.

[srisub1]

Seems like Prisma 2.8.0 is released, but this issue is still not fixed. For those of us who use nexus, we simply might not be upgrade prisma, until this is fixed. Is there a plan / timeline on this.

[hatchli]

The nexus-plugin-prisma teams silence on the matter is really worrying me. I'm not keen on switching, but it's odd how there are no comments at all from them acknowledging the matter...

[jca41]

Aso having this issue with 0.20 (prisma client 2.7.0), is there any version combination of nexus-plugin-prisma and @prisma/client that hide this issue?

If i downgrade to 0.18.2 i get different errors..

[ifndefdeadmau5]

@jca41 Looks like sticking with v0.17.0 until this problem is solved is your best bet

[jca41]

@jca41 Looks like sticking with v0.17.0 until this problem is solved is your best bet

Thanks, i went in and converted every update mutation to set :D

[lvauvillier]

The problem is related to the way union types are flattened. The flatten function is here:
https://github.com/graphql-nexus/nexus-plugin-prisma/blob/master/src/dmmf/transformer.ts#L115

I think it will be easy to add an option to configure the default behavior.
@jasonkuhrt do you have a suggestion on how an option can fit in here?

[jasonkuhrt]

@lvauvillier Simple PRs welcome, e.g. root level configuration. More sophisticated things like #598 should be left to the core team.

[lvauvillier]

@jasonkuhrt Thanks. I just submit a PR.

[hatchli]

Any update on the PR @lvauvillier ?

[lvauvillier]

@hatchli the PR is waiting to be reviewed and merged (#899)

[jasonkuhrt]

@lvauvillier We're awaiting tests and docs as mentioned in my feedback :)

[lvauvillier]

@jasonkuhrt done!