-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Conversation
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!
@michalsn Thanks.
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.
Add more case test
@@ -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.' |
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.
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.
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.
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!
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 the explanation.
@michalsn rebase is needed |
3e3e722
to
7742124
Compare
@samsonasik Thanks, done. |
Co-authored-by: Pooya Parsa <[email protected]>
7742124
to
3715280
Compare
Description
This PR fixes the case insensitivity option in the
like()
method when we deal with accented characters.Closes #9236
Checklist: