Skip to content
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

Implement functions UCASE and LCASE #1060

Merged
merged 8 commits into from
Aug 21, 2023
Merged

Conversation

joka921
Copy link
Member

@joka921 joka921 commented Aug 19, 2023

Missing: Unit tests and E2E tests, those will be added once the SUBSTR PR is merged.

Missing: Unit tests and E2E tests, those will be added once the SUBSTR PR is merged.
Copy link
Member

@hannahbast hannahbast left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice and simple. A minor comment and a minor question. And the builds still fail.

Comment on lines 145 to 158
// Get the uppercase value. For details see `getLowercaseUtf8` above
inline std::string getUppercaseUtf8(std::string_view s) {
std::string result;
icu::StringByteSink<std::string> sink(&result);
UErrorCode err = U_ZERO_ERROR;
icu::CaseMap::utf8ToUpper(
"", 0, icu::StringPiece{s.data(), static_cast<int32_t>(s.size())}, sink,
nullptr, err);
if (U_FAILURE(err)) {
throw std::runtime_error(u_errorName(err));
}
return result;
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the almost identical code, how about a helper function utf8StringTransform, which takes a std::string_view and the transformation function as arguments?

Also, it looks like it would be more consistent to name the two functions based on this helper function utf8StringToLower (instead of getLowercaseUtf8) and utf8StringToUpper (instead of getUppercaseUtf8).

Comment on lines +69 to +71
if (!input.has_value()) {
return Id::makeUndefined();
} else {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A cascaded question: When exactly is the argument std.:nullopt, when the argument given in the SPARQL query was not actually a string? If yes, is the result of a built-in SPARQL function taking one or several string as argument always UNDEF when one of these arguments is not a string? If yes, should this be handled in the functions or outside? I am asking because for the numeric functions the return Id::makeUndefined happens elsewhere.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is actually a good idea.
For the Numeric functions we have a wrapper that handles the "invalid input" -> expression error -> UNDEF result case automagically,
But we could extend this to all kinds of expressions, s.t. for example the string function implementations only need to handle a string instead of an std::optional<std::string>.
I will think of something and integrate it into one of the next PRs.

@codecov
Copy link

codecov bot commented Aug 19, 2023

Codecov Report

Patch coverage: 52.63% and project coverage change: -0.06% ⚠️

Comparison is base (f2e7e89) 78.29% compared to head (720f4b3) 78.24%.
Report is 3 commits behind head on master.

❗ Current head 720f4b3 differs from pull request most recent head fa48d27. Consider uploading reports for the commit fa48d27 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1060      +/-   ##
==========================================
- Coverage   78.29%   78.24%   -0.06%     
==========================================
  Files         276      276              
  Lines       25703    25740      +37     
  Branches     3144     3149       +5     
==========================================
+ Hits        20123    20139      +16     
- Misses       4378     4395      +17     
- Partials     1202     1206       +4     
Files Changed Coverage Δ
...ne/sparqlExpressions/RelationalExpressionHelpers.h 68.36% <0.00%> (-0.71%) ⬇️
src/engine/sparqlExpressions/StringExpressions.cpp 73.21% <33.33%> (-26.79%) ⬇️
src/util/StringUtils.h 77.05% <75.00%> (-0.16%) ⬇️
src/parser/sparqlParser/SparqlQleverVisitor.cpp 91.25% <100.00%> (+0.02%) ⬆️

... and 2 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Member

@hannahbast hannahbast left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome!

@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 2 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

warning The version of Java (11.0.17) you have used to run this analysis is deprecated and we will stop accepting it soon. Please update to at least Java 17.
Read more here

@hannahbast hannahbast changed the title Add support for UCASE and LCASE Implement functions UCASE and LCASE Aug 21, 2023
@hannahbast hannahbast merged commit 015956f into ad-freiburg:master Aug 21, 2023
@joka921 joka921 deleted the ucase-lcase branch December 7, 2023 09:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants