CRUD naming/nesting strategies

[Weakky]

Description

Which naming convention do you prefer for mutations:

• create/update/deleteOneSomething
• create/update/deleteSomething ?

I personally prefer create/update/deleteSomething, that's how it used to be on Prisma 1. We already updated Query.findOneSomething and Query.findManySomething to Query.something & Query.somethings. It'd probably feel better to follow the same pattern

Related to #388

[jasonkuhrt]

Proposal 1

Pattern

<create|read|update|upsert|delete><M|M Plural>

Examples

t.crud.createUser()
t.crud.readUser()
t.crud.readPosts()
t.crud.updateUsers()
t.crud.deletePost()

Proposal 2

Pattern

<M>.<create|read[Many]|update[Many]|delete|upsert>

Examples

t.crud.user.create()
t.crud.user.read()
t.crud.user.updateMany()

t.crud.post.readMany()
t.crud.post.delete()

Proposal 3

Pattern

<M>.<create|read|update|delete|upsert>

Examples

t.crud.user.create()
t.crud.user.read()
t.crud.user.update({ many: true })

t.crud.post.read({ many: true })
t.crud.post.delete()

Proposal 4

Pattern

<M>.[many.]<create|read|update|delete|upsert>

Examples

t.crud.user.create()
t.crud.user.read()
t.crud.user.many.update()

t.crud.post.many.read()
t.crud.post.delete()

[jasonkuhrt]

1. I think the presence of read in the API

   1. reads nicely (namely not worse than without)
   2. is more consistent with functions from the other crud groups
   3. supports the mental model better, by emphasizing the C.R.U.D. aspect

   
   
   

2. I am not sure the assumption baked into t.crud.user.update({ many: true }) is optimal, which is that, [almost] all many-enabled CRUDs will have single-enabled too.

   We could allow: t.crud.user.update({ many: true, one: false }) to break the assumption.

   A nice thing about this API is that for each resource type (user, post, etc.) there is exactly one entry for each C.R.U.D dimension. The more I think about this the more I like it. The reason is, the emphasis on facts.

   1. What CRUD dimensions is this resource available under?
   2. For each dimension, what variations?

   
   

   Casting ii as config within i feels appropiate.

   We could support operation publisher option configuration like so:

   t.crud.user.read({ many: { filtering: true, pagination: false }})

[Albert-Gao]

Proposal 2 seems beautiful, vote for it.

t.crud.user.read()
t.crud.post.readMany()

I get the domain: user, then I want to execute some actions against it, this fits the mantle model of writing code.

For each action, 2 versions, single and many. Especially when using Typescript, the auto-completion will be perfect, you type rea, then both read and readMany would pop up. And this is one of the reasons it is better than proposal 1, which is, for proposal 1, after typing creat, there will be too many options once there are enough models. But for proposal 2, the filtering has already been done after doing t.crud.user.

For proposal 3, pass the many intention as a parameter is fine, but semantically, read and readMany seems to have a more readable experience and nicely decouple to me.

Not a big fan of proposal 4, as proposal 2 fulfills the same requirement, but open to hear more.