-
Notifications
You must be signed in to change notification settings - Fork 280
Modified capitalization in metadata queries (#1896) #1921
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modified capitalization in metadata queries (#1896) #1921
Conversation
Modified metadata queries to use proper case to avoid "field not found" errors whether database collation is sensitive or not
@microsoft-github-policy-service agree |
/azp run |
Azure Pipelines successfully started running 5 pipeline(s). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you for making these changes to enable compat with case sensitive db collations! few things to update then should be good to go.
Co-authored-by: Sean Leonard <sean.leonard@microsoft.com>
Co-authored-by: Sean Leonard <sean.leonard@microsoft.com>
Co-authored-by: Sean Leonard <sean.leonard@microsoft.com>
Co-authored-by: Sean Leonard <sean.leonard@microsoft.com>
Code change suggestions reviewed and accepted. Thanks for the heads up on the tab characters. |
/azp run |
Azure Pipelines successfully started running 5 pipeline(s). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for making these changes!
/azp run |
Azure Pipelines successfully started running 5 pipeline(s). |
/azp run |
Azure Pipelines successfully started running 2 pipeline(s). |
@gamewizzzz, the MySQL/PgSQL tests are failing since their query builders need to be updated as well. Could you please fix it in this function:
|
@gamewizzzz, are you still working on this? |
No. Shortly after getting the test build to run successfully, one of the
other branches changed something to the point I could not upgrade the tool
properly on the test environment. Haven't had time to try again since.
…On Tue, Jun 18, 2024 at 5:55 PM Erwin Hekkert ***@***.***> wrote:
@gamewizzzz <https://github.com/gamewizzzz>, are you still working on
this?
—
Reply to this email directly, view it on GitHub
<#1921 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADRTLSCZNQQBRNHO3WE7YLDZIC3GVAVCNFSM6AAAAABAOMCOPSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZXGIYTQNJWGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Hi @Aniruddh25 . Any help from the DAB team to finish this PR? |
/azp run |
@sander1095 - yes, we will take it forward and merge this. |
/azp run |
1 similar comment
/azp run |
/azp run |
The example you reference in "image.png" shows double quotes, I'm not sure
how that helps your argument.
Looking at line 231 where the quotes are used, I would say the quotes are
needed. In line 231, dynamic SQL syntax is being assigned to a string
variable so it can be passed as an argument to another command that
executes the SQL. That can't be done without at least one set of quotes
since you have spaces in the statement. The most you could do is combine
lines 231 and 232, but then again the code is broken out that way to help
with readability.
I agree with your point about the styling inconsistency of single quotes
(') vs double quotes ("). The inconsistency costs extra time in explaining
and transfering to other maintainers. However, there are legitimate reasons
to use one over the other in MS SQL queries:
- Variable expansion. Double quotes allow you to pre-expand variables
before assigning the result to the string, whereas single quotes you
cannot. You may be able to get away with wrapping line 231 in single
quotes, but line 232 you cannot because schemaParamName is being expanded
- Flexibility of SQL syntax. Double quotes still allow you to embed
single quotes in the SQL query without much headache. In line 232, a string
literal is being referenced in the filter of the dynamic SQL, and is
wrapped in single quotes. If you tried to use single quotes to wrap the
whole statement, you will have to escape the single quotes of the literal.
Once you start having to do escaped characters, it gets a little more
difficult to work with them when debugging errors
…On Tue, Jul 23, 2024 at 6:21 PM aaronburtle ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In src/Core/Resolvers/PostgresQueryBuilder.cs
<#1921 (comment)>
:
> @@ -228,7 +228,7 @@ public string BuildStoredProcedureResultDetailsQuery(string databaseObjectName)
/// <inheritdoc/>
public string BuildQueryToGetReadOnlyColumns(string schemaParamName, string tableParamName)
{
- string query = "SELECT attname AS column_name FROM pg_attribute " +
+ string query = "SELECT attname AS \"COLUMN_NAME\" FROM pg_attribute " +
Are quotes needed here? The other statements don't seem to make use of
double quotes, for example
image.png (view on web)
<https://github.com/user-attachments/assets/8e7364e6-9194-4e65-94c0-75f269a141cf>
For style consistency would be better if we can remove these, or if quotes
are needed see if single quote will work since we already use some single
quotes in queries in this class.
—
Reply to this email directly, view it on GitHub
<#1921 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADRTLSHGE6RBBDBV6KSLKTLZN3QOPAVCNFSM6AAAAABAOMCOPSVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDCOJVGI2DQMJSGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I probably wasn't clear enough, but I am referencing the hard coded and escaped double quotes around I should have mentioned the helper function but it slipped my mind and I was confused why we had escaped double quotes there. |
/azp run |
2 similar comments
/azp run |
/azp run |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
## Why make this change? - Resolves #1896 ## What is this change? - These changes impact API builder startup. The query output has not been modified, but certain field references are capitalized. - The proper case is used to avoid "field not found" and "key field not found" errors when the database collation is case-sensitive. ## How was this tested? - [x] Integration Tests - Ran locally; about 5 tests failed, but it was the same ones that failed before modifications - [ ] Unit Tests ## Sample Request(s) - N/A --------- Co-authored-by: Sean Leonard <sean.leonard@microsoft.com> Co-authored-by: Aniruddh Munde <anmunde@microsoft.com> Co-authored-by: RubenCerna2079 <32799214+RubenCerna2079@users.noreply.github.com> Co-authored-by: Ruben Cerna <rcernaserna@microsoft.com>
## Port metadata - Porting from `main` to `release/1.2` - Issue: #1896 - PR: #1921 ## Why make this change? - Resolves #1896 ## What is this change? - These changes impact API builder startup. The query output has not been modified, but certain field references are capitalized. - The proper case is used to avoid "field not found" and "key field not found" errors when the database collation is case-sensitive. ## How was this tested? - [x] Integration Tests - Ran locally; about 5 tests failed, but it was the same ones that failed before modifications - [ ] Unit Tests ## Sample Request(s) - N/A Co-authored-by: gamewizzzz <gamewizzzz@gmail.com> Co-authored-by: Aniruddh Munde <anmunde@microsoft.com> Co-authored-by: RubenCerna2079 <32799214+RubenCerna2079@users.noreply.github.com> Co-authored-by: Ruben Cerna <rcernaserna@microsoft.com>
Why make this change?
What is this change?
How was this tested?
Sample Request(s)