fix(db): sql error with custom table prefix #970
Merged
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.
fixes #969
In v2.9.0, modifications were made to the API to add search functionality for the dashboard's page list and user list. However, an issue arose in #969 because users employed a custom database table prefix
atk_
(default is empty). The problem occurred because the SQL queries for the dashboard page search function used the hard-coded table namepages
instead of the user's actual table nameatk_pages
.On a deeper level, why must this query use the table name
pages
? This is due to legacy reasons where thekey
field name does not align with best practices, causing ambiguity with SQL syntax. Directly using thekey
field name leads to SQL syntax errors, while usingpages.key
(table name dot field name format) avoids errors.Given the time and testing maintenance costs, altering the data structure is challenging. However, renaming the
key
field inentity.Pages
to something else is a goal for future versions.Supplement: I noticed errors in the unit tests. I found that in previous versions, the unit tests did not cover test cases that used custom database table prefixes. Additionally, through code inspection, I discovered many instances of hardcoded table names, which could potentially cause issues (similar to the problems mentioned earlier). Therefore, in this PR, I have made further modifications to replace the hardcoded parts with calls to
app.Dao().GetTableName
to obtain the actual database table names (with the custom table prefix).