Support for a Union type

[matthewmueller]

Problem

Unions data types are handy in features like feeds. Right now it's difficult to model unions in Prisma and it would be great if we could make this feature higher-level.

You'll also find community use cases in this thread.

Possible solution

Facebook's feed is a good example. The feed has Videos, Photos and Posts.

Modeled in Typescript

type Activity = Video | Photo | Message

type Video = {
  type: 'video'
  url: string
  media: 'webm' | 'mp4'
}

type Photo = {
  type: 'photo'
  width: number
  height: number
}

type Post = {
  type: 'post'
  message: string
}

Modeled in Postgres

create sequence bigserial activity_id;

create table videos (
  id activity_id primary key,
  url text not null,
  media text not null
)

create table photos (
  id activity_id primary key,
  width int,
  height int
)

create table posts (
  id activity_id primary key,
  message text
)

Alternatives

There are lots of alternative table inheritance schemes. We'd need to weigh the pros and cons of each.

[matthewmueller]

Alternative approach to union types in Rails world: https://github.com/rails/rails/pull/39341/files#diff-9aa331e58766cbbcd7fac37f75ee07b3R6

[brielov]

Is there any news on this?

[brielov]

Sorry to be iterative on this, but is such a common use case. I am currently building an activity feed for a client who needs to know which user creates, modifies, deletes, etc a particular resource and I'm having trouble deciding what approach to follow.

I'm using nexus with nexus-plugin-prisma and I have something like this:

enum ActivityAction {
  CREATE
  DELETE
  LOGIN
  UPDATE
}

model Activity {
  id          String         @id @default(cuid())
  action      ActivityAction
  createdAt   DateTime       @default(now())
  targetId    String?
  targetModel String? // this should be something like Post | Comment | Project
  user        User           @relation(fields: [userId], references: [id])
  userId      String
}

In nexus:

schema.objectType({
  name: 'Activity',
  definition(t) {
    t.model.id()
    t.model.user()
    t.model.action()
    t.model.createdAt()
    t.field('resource', {
      type: 'ActivityFeed',
      resolve(root, _args, ctx) {
        if (!(root.targetId && root.targetModel)) return null
        // @ts-ignore
        return ctx.db[root.targetModel].findOne({ where: { id: root.targetId } })
      },
    })
  },
})

I don't know if this is right or wrong but feels hacky as hell, not to mention the n+1 problem.

[akshaylive]

+1 on this.

I haven't thought too much about this, but agree with brielov above.

As far as implementation is concerned, something like this would be amazing:

  targetId      String
  targetType    String
  target        Post(references: [id]) | Comment(references: [id]) | Project(references: [id]) @relation(disambiguator: [targetType], fields: [targetId])

With an optional support of

  targetId      String
  targetType    String
  target        Post | Comment | Project @relation(disambiguator: [targetType], fields: [targetId], references: [id])

[akshaylive]

I was really curious how Prisma worked under the hood so I downloaded the prisma-engines repo to start hacking away as that repo holds the pest grammar for Prisma. Here is my finding so far -

1. Making a grammar change to support something like the above is doable but it'll require a lot of work.
2. Doing something like the following is much simpler to implement in prisma-engines as it requires no grammar change:

   targetId      String
   targetType    String
   target        Polymorphic @relation(disambiguator: targetType, fields: [targetId], references: [Post([id]), Comment([id]), Project([id])])
   

3. It is very tempting to introduce a separate dml field type (ex: Polymorphic) in prisma-engines to support this. However, doing something like this will also require plenty of code changes (although not as much as a grammar change). To minimize code changes, we could reuse dml field type of Relation and add additional enum to mention relation type.

[samwightt]

+1 for this as well, there's not really a good way to do this currently.

[akshaylive]

I've started partial work on this but my Rust skills are... Rusty. :D Never worked on it and I'm not used to the strong ownership model so the code is not great.

After pondering over the schema for a while, this one seems to be the simplest to implement, although verbose:

  targetType String
  targetId   String
  target     Post @relation(fields: [targetId], references: [id], disambiguator: targetType)
  target     Comment @relation(fields: [targetId], references: [id], disambiguator: targetType)

I've pushed two branches on my clone of Prisma.

1. DMMF which adds to input types
2. DMMF which creates a new model called OneOfModelModelModel..

The former is the cleaner of the two approaches as it may not even require a prisma client change. The following needs to be done -

1. Add validation to dmmf as the ast validation was removed to accommodate the change
   1.1. If disambiguator exists, an associated String field must exist on the same model
   1.1. If multiple fields have the same name, ensure that the disambiguators should be the same
   1.1. If multiple fields have the same name, ensure that the disambiguators should exist (i.e; should not be empty)
   1.1. If multiple fields have the same name, ensure that the arity is the same
2. Create similar changes for Update and Where - this is fairly straight forward - can work on it by next weekend
3. Need to ensure that the disambiguator field should not be in the DMMF as it is redundant. (note: I'm not sure if this is a good idea, but makes sense logically).
4. Need to add the where clause implicitly.
5. lot of many such changes in db layer.

Still a lot of work to be done. Could someone from Prisma validate if this is a reasonable approach? If so, can someone help in the efforts? :)

(tagging @matthewmueller as Matthew has committed to Prisma in the past)