Fix mutations with camelCase table names #8740
Merged
+3
−12
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Weiko
commented
Nov 25, 2024
| const nonFormattedDeletedObjectRecords = await queryBuilder | ||
| .where(`"${tableName}".id = :id`, { |
There was a problem hiding this comment.
We already wanted to fix that bug earlier by computing the table name in the destroy endpoint but it was not done everywhere. Let's use the new fix so we don't have the compute it.
There was a problem hiding this comment.
PR Summary
This PR fixes issues with camelCase table names in mutations by reordering query builder method chains, particularly affecting the workspaceMember table's soft deletion functionality.
- Reordered
.where()clause to come after.softDelete()ingraphql-query-delete-one-resolver.service.tsto preserve proper table name casing - Modified query builder chain in
graphql-query-destroy-one-resolver.service.tsto simplify table name handling - Adjusted
graphql-query-restore-one-resolver.service.tsto place.restore()before.where()for consistent casing behavior - Fixed issue where table names weren't properly quoted in SQL queries when using certain QueryBuilder methods
3 file(s) reviewed, no comment(s)
Edit PR Review Bot Settings | Greptile
charlesBochet
approved these changes
Nov 26, 2024
Weiko
added a commit
that referenced
this pull request
Nov 26, 2024
## Context Some mutations are not working properly, workspaceMember soft deletion for example. workspaceMember being a camelCase table name, it's probably not propagated properly to pgql (which needs double quote for the table name to keep it as camelCase) I didn't have time to dig too much but if the `where` is before `softDelete`, the query is `WHERE workspaceMember.id = $1` while if it's after, the query becomes `WHERE id = $1`. Probably due to the fact that once you call delete/softDelete/update, the standard builder (SelectQueryBuilder) becomes a DeleteQueryBuilder/etc... and filters are not handled the same way.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context
Some mutations are not working properly, workspaceMember soft deletion for example. workspaceMember being a camelCase table name, it's probably not propagated properly to pgql (which needs double quote for the table name to keep it as camelCase)
I didn't have time to dig too much but if the
whereis beforesoftDelete, the query isWHERE workspaceMember.id = $1while if it's after, the query becomesWHERE id = $1.Probably due to the fact that once you call delete/softDelete/update, the standard builder (SelectQueryBuilder) becomes a DeleteQueryBuilder/etc... and filters are not handled the same way.