TypeOrm Inheritance support POC

[lenybernard]

Hello,

I've just made a proof of concept of TypeORM inheritance support with this library, I've made a PR here : lenybernard/nestjs-playground#1

Note

I've pushed a ZooModule with the proof of concept with nestjs-query and a "classic" way (without nestjs-query). You can test it by disabling ZooModule and re-enabling ZooClassicModule in app.module.ts.

It works "as is" and I think It could be interesting to add a section in the documentation, I could propose a PR if you want @TriPSs but it needs to be improved before, there is some weird things.

For me, there is the following things to fix :

• We should be able to declare the base entity as Abstract
• We shouldn't have to declare both @ObjectType AND @InterfaceType on the abstract object
• We shouldn't have to add a fake dtype to resolve types (in resolveType function), it works well in classic way (see example in ZooClassicModule)

Thank you for the review !

[TriPSs]

I have never used TableInheritance but the "fake" db type is also done in the TypeORM documentation?

Regarding your other points:

1. Why is this not possible?
2. I do not see why this is a issue? Seems like the classic also has it so I do not see why you want this to be removed?

Never knew this existed in TypeORM, pretty cool.

[lenybernard]

The fake dtype is a workaround to make resolveType fn works. I've put a classic example, you can see there isn't any need of an additional dtype cause the type resolution is made automatically (I don't know why).

1. Why is this not possible?

If you talk about the abstract issue, it's because DTOClass and EntityClass options doesn't allow it :

2. I do not see why this is a issue? Seems like the classic also has it so I do not see why you want this to be removed?

Actually, it doesn't really bother me but for me @ObjectType stands for concrete resources and @InterfaceType defines another type of graphql object, the role of the abstract is not exists as an object but as a graphql union finally.

[TriPSs]

The fake dtype is a workaround to make resolveType fn works. I've put a classic example, you can see there isn't any need of an additional dtype cause the type resolution is made automatically (I don't know why).

Could elaborate a bit about what "fake dtype" means? Aperently I thought it was something different.