typeorm
typeorm copied to clipboard
DELETE with QueryBuilder doesn't honor table name aliases
Issue type:
[ ] question [x] bug report [ ] feature request [ ] documentation issue
Database system/driver:
[ ] cordova
[ ] mongodb
[ ] mssql
[ ] mysql / mariadb
[ ] oracle
[x] postgres
[ ] cockroachdb
[ ] sqlite
[ ] sqljs
[ ] react-native
[ ] expo
TypeORM version:
[ ] latest
[ ] @next
[x] 0.2.24 (or put your version here)
Steps to reproduce or a small repository showing the problem:
I might be wrong, but I believe that setting the table alias in the from(...) isn't working in a DeleteQueryBuilder (see example below) if the user want to use explicit table names.
A fix would be to honor aliasing, or to remove it from the from method signature.
Note that an easy workaround is not to specify the table name, but maybe it won't work for more complex queries.
getManager().transaction(async (mgr) => {
await mgr
.createQueryBuilder()
.delete()
.from(User, 'u'). // actual table is 'users'
.where('u.id = :userId', { userId })
.execute();
});
can you try instead :
getManager().transaction(async (mgr) => {
await mgr
.createQueryBuilder()
.delete()
.from(User). // actual table is 'users'
.where('id = :userId', { userId })
.execute();
});
https://typeorm.io/#/delete-query-builder/delete
Note that an easy workaround is not to specify the table name, but maybe it won't work for more complex queries.
Sorry if my first comment above was unclear: this fix does work, but it still means the API is misleading because a developer would be tempted to assume aliases work within a DeleteQueryBuilder without understanding why it fails. A fix would be to remove the second argument of the .from method when in a DeleteQueryBuilder, or implement aliasing.
It also fails if you set alias in createQueryBuilder
getManager().transaction(async (mgr) => { await mgr .createQueryBuilder('u') .delete() .where('u.id = :userId', { userId }) .execute(); });
The multi-part identifier "u.id" could not be bound.
I recently wasted some time trying to figure this one out as well. The issue has not yet been addressed.
I'm also facing the same issue.
TypeORM has returned to active development after recently transitioning to new leadership (see related announcement).
As part of the new team's efforts to prioritise work on the project moving forward, it is necessary to clean up the backlog of stale issues.
🧹 This issue is being automatically closed because it has had no activity in the last 6 months. If you believe this issue is still relevant, feel free to comment below and the maintainers may reopen it. Thank you for your contribution.