QueryBuilder with type safety & column definitions

[baba43]

Issue type:

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

Database system/driver:

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

TypeORM version:

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

Steps to reproduce or a small repository showing the problem:

First of all, I would like to thank you for this project. I love TypeORM for the type safety it brings us. This is especially important in my current project as the structure of the database changes frequently. Compilation errors help to avoid mistakes.

Since the current database model is not well designed, but I have to accept it as given, many columns have been renamed. It's great that this is so easy with column definition.

For most queries, the "find api" has been enough for me. It works wonderfully and guarantees type safety (with minimal adjustments).

Then I wanted to create a simple 'GROUP BY' and realized that the 'find api' was not enough. So I looked at the QueryBuilder and found that it guarantees virtually no type safety? All methods work with strings, unlike the FindOneOptions.

Naive as I am, I created my own interface, which should work similar to FindOneOptions.

export declare class TypedSelectQueryBuilder <T> extends SelectQueryBuilder <T> {
  // @ ts-ignore
  groupBy (groupBy: keyof T): this;
}

Auto-completion and type-safety worked, but the code did not do what it should. Why? Because the names of the columns did not fit. If I understand it correctly, the builder works independently of the column definitions.

So, my question is, which is the right way to implement type safety with a single source of truth (column definitions)? Or is there currently no solution to this problem?

I'm sorry if a similar question has already been asked. I appreciate tips and references to related issues.

Finally, I would like to thank you again for this project and all the effort you put into it. Keep it up.

[imnotjames]

Absolutely agree on type safety being needed for these kinds of things - we just aren't there yet. There's an issue open I'll be marking this as a duplicate of.

If you'd like to discuss alternatives, workarounds, etc, please check out the community slack or check TypeORM's documentation page on other support avenues - cheers!

[imnotjames]

Duplicate of #3416