Polymorphic Relationship

Issue type:

[ ] question [ ] bug report [x ] feature request [ ] documentation issue

Database system/driver:

[ ] cordova [ ] mongodb [ ] mssql [ x] mysql / mariadb [ ] oracle [ x] postgres [ ] cockroachdb [x ] sqlite [ ] sqljs [ ] react-native [ ] expo

TypeORM version:

[ ] latest [ ] @next [ ] 0.x.x (or put your version here)

Steps to reproduce or a small repository showing the problem:

[onichandame]

It is great that a 3rd party package solves the problem. But polymorphic relation is close to the core functions of an ORM in my opinion, would it make sense to merge this function into typeorm itself?

[bashleigh]

I’ve been implementing a repository which handles polymorphic children and polymorphic parents. I was going to open source it but if I’m honest, I would rather implement it into typeorm!

@Entity()
export class PhotoEntity implements PolymorphicChildInterface {

  @PolymorphicParent(() => [UserEntity, MerchantEntity])
  owner: UserEntity | MerchantEntity;

  @Column()
  entityId: number; // required for PolymorphicChildInterface

  @Column()
  entityType: string; // required for PolymorphicChildInterface

}

@Entity()
export class UserEntity {

  @PolymorphicChildren(() => PhotoEntity, {
    eager: false,
  })
  photos: PhotoEntity[];

}

@Entity('merchants')
export class MerchantEntity extends AbstractEntity {
  @ManyToMany(t => UserEntity, user => user.merchants)
  users: UserEntity[];

  @PolymorphicChildren(() => PhotoEntity, {
    eager: false,
  })
  photos: PhotoEntity[];
}

These are the available options for the above decorators

export interface PolymorphicChildrenDecoratorOptionsInterface {
  primaryColumn?: string;
  hasMany?: boolean;
  cascade?: boolean;
  eager?: boolean;
  deleteBeforeUpdate?: boolean;
  entityTypeColumn?: string;
  entityTypeId?: string;
}

export interface PolymorphicParentDecoratorOptionsInterface {
  deleteBeforeUpdate?: boolean;
  primaryColumn?: string;
  hasMany?: boolean;
  cascade?: boolean;
  eager?: boolean;
  entityTypeColumn?: string;
  entityTypeId?: string;
}

A downside is I’m not currently using a reverse relationship check?

I’ve implemented this in a way outside of typeORM so I’ve just made an abstract repository that handles hydrating on {findOne, find} and saving etc. I’d love to implement this for typeORM! When I’m 100% happy with it, I’ll create a repo with it on github 😃

I did however start writing a medium post about it https://medium.com/p/96ad63cb8d0b/edit I’ve since reimplemented this entirely although some of the basic logic is the same!

I’ve implemented this so you can really customise it! You can have many different parents, many different children AND! Singular + array returns so you can have a parent of 2 types yet return one and the reverse for children. There is no overall difference for how the decorators are handled other than the default values for the options.

There’s only one thing holding me back at the moment and that’s whether to implement a race promise for singular relations or find all and determine which to return as we’d only require one entity? Not sure what decision to make! Not sure if to throw an exception if 2 entities are found? Or even just bypass the typing and return an array instead of 1 entity but I don’t want to do that!

If you’d like to see it as is I can upload it now 😃

I’m also considering creating a PolymorphicHasManyThrough type relationship for where my user can have many photos through a merchant.

Another blocker is I have created an interface:

export interface PolymorphicChildInterface {
  entityId: number;
  entityType: string;
}

But I’ve also implemented the ability (not that I’m using it currently) to change the child column names. So I’m trying to think of a possible way I could change the key names? The default for entityTypeColumn is entityType and entityIdColumn is entityId.