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

fix: case-insensitivity in the like() method when in use with accented characters #9238

Merged
merged 7 commits into from
Nov 3, 2024

Conversation

michalsn
Copy link
Member

Description
This PR fixes the case insensitivity option in the like() method when we deal with accented characters.

Closes #9236

Checklist:

  • Securely signed commits
  • Component(s) with PHPDoc blocks, only if necessary or adds value
  • Unit testing, with >80% coverage
  • User guide updated
  • Conforms to style guide

@michalsn michalsn added the bug Verified issues on the current code behavior or pull requests that will fix them label Oct 25, 2024
Copy link
Contributor

@datamweb datamweb left a comment

Choose a reason for hiding this comment

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

LGTM!
@michalsn Thanks.

Copy link
Collaborator

@ddevsr ddevsr left a comment

Choose a reason for hiding this comment

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

@@ -79,6 +79,12 @@ public function testLikeCaseInsensitive(): void
#[DataProvider('provideMultibyteCharacters')]
public function testLikeCaseInsensitiveWithMultibyteCharacter(string $match, string $result): void
{
if ($this->db->DBDriver === 'SQLSRV') {
$this->markTestSkipped(
'Currently Builder class does not fully support Unicode strings in SQLSRV.'
Copy link
Contributor

Choose a reason for hiding this comment

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

To be honest, I didn’t fully understand the details of this topic. While researching, I came across the following information:

nchar-and-nvarchar-transact-sql

"Character data types that are either fixed-size, nchar, or variable-size, nvarchar. In SQL Server 2012 (11.x) and later versions, when a Supplementary Character (SC) enabled collation is used, these data types store the full range of Unicode character data and use the UTF-16 character encoding. If a non-SC collation is specified, then these data types store only the subset of character data supported by the UCS-2 character encoding."

Based on this information, it seems that when an SC collation is used, there shouldn’t be any limitations on Unicode character support, as UTF-16 is capable of storing the full range of Unicode characters.

If possible, please provide additional documentation or clarification on these changes and specify how the SC collation should be applied in this PR.

Copy link
Member Author

Choose a reason for hiding this comment

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

I was going to post the details as a bug report, but I gave it another try after your comment.

You are right. When I was checking this, I set collation only for the value field. Apparently, we have to set it for the entire database to work properly. Because of this, I was only able to add Unicode string using N prefix.

Thank you!

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for the explanation.

@samsonasik
Copy link
Member

@michalsn rebase is needed

@michalsn
Copy link
Member Author

@samsonasik Thanks, done.

@michalsn michalsn merged commit fc19b69 into codeigniter4:develop Nov 3, 2024
40 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Verified issues on the current code behavior or pull requests that will fix them
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Bug: insensitive like query failing with multibyte characters
4 participants