Relation decorators: allow to pass string instead of typeFunction

[haschu]

Issue type:

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

---

To define table relations using decorators, this is the current way:

Photo.ts

    @ManyToOne(type => User, user => user.photos)
    user: User;

User.ts

    @OneToMany(type => Photo, photo => photo.user)
    photos: Photo[];

This works fine on Node.js, but can cause circular dependency issues on the frontend side (e.g. when using Angular CLI). See: #2059 or #1290

We could overcome those issues, if the following would be possible:

Photo.ts

    @ManyToOne('User', 'photos')
    user: User;

User.ts

    @OneToMany('Photo', 'user')
    photos: Photo[];

This should be fairly easy to implement, as it turns out that TypeORM already supports string instead of types (e.g. when using EntitySchema) - the only thing to do is to adjust the typeFunction type of the decorator functions.

@pleerock If that feature would be ok I could post a PR :)

[haschu]

PR is submitted.

As an example, the following pattern would now prevent circular dependency issues with @OneToMany/@ManyToOne (using abstract classes would be more suitable for bigger entities to prevent duplicate code):

IUser.ts

export interface IUser {

  id: number;

  name: string;

}

IPhoto.ts

export interface IPhoto {

  id: number;

  url: string;

}

User.ts

@Entity()
export class User implements IUser {

  @PrimaryGeneratedColumn()
  id: number;

  @Column()
  name: string;

  @OneToMany('Photo', 'user')
  photos: IPhoto[];

}

Photo.ts

@Entity()
export class Photo implements IPhoto {

  @PrimaryGeneratedColumn()
  id: number;

  @Column()
  url: string;

  @ManyToOne('User', 'photos')
  user: IUser;

}

[jordancue]

@haschu great work!

[haschu]

@jordancue Thank you :) Hope 0.2.18 will be released soon.

[Michael-Dawkins]

In my angular app, I have set "showCircularDependencies": false in the angular.json to simply ignore the circular dependency messages and it fixed my issues, it looks clean to me because there indeed are cycles in my typeORM models and this is fine.
The only downside I see to this approach is that, sometimes, the circular dep warning can be helpful to detect an actual code smell.

Am I missing something?

What I prefer with this method over using strings is the maintainability aspect, I can still refactor the name of a class and have my IDE propagate the rename from the db down to the frontend.

[haschu]

@Michael-Dawkins I guess you don't miss anything :)

The only downside I see to this approach is that, sometimes, the circular dep warning can be helpful to detect an actual code smell

Beware that circular dependencies can be pretty dangerous, as they lead to null/undefined references that may be hard to debug. That's why I find the warnings are overall helpful.

TypeORM can deal with it, because it forwards the reference using a typeFunction. That's btw. the reason you have to write @OneToMany(type => Something) instead of @OneToMany(Something) - because Something can be null/undefined at this time.

But if you by accident introduce another circular dependency, the compiler won't warn you, and debugging can be a hard time.

[Michael-Dawkins]

Thank you for the explanation.

It seemed weird to me at first why typeORM does not use @OneToMany(Something), thank you for the insight about the fact it may be undefined if evaluated too early.

[haschu]

You're welcome :)

As you you're using Angular: have a look a forwardRef, it's the exact same use-case.