You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Ekaterina Dimitrova (Jira)" <ji...@apache.org> on 2021/02/18 19:59:00 UTC
[jira] [Comment Edited] (CASSANDRA-16429) Fix incorrect encoding
for strings can be UTF8
[ https://issues.apache.org/jira/browse/CASSANDRA-16429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17286701#comment-17286701 ]
Ekaterina Dimitrova edited comment on CASSANDRA-16429 at 2/18/21, 7:58 PM:
---------------------------------------------------------------------------
As someone who was not familiar with the initial work and looks at it with fresh eyes, I have two directions of thinking:
* A group of users who were using UTF8 in previous versions (and I can imagine them not being 1 or 2) observe a breaking change of expected behavior which is not documented.
* We are just before a RC I believe and we promised no breaking changes anymore and now we revert, at least partially, a performance improvement. Then a different part of users gets disappointed as they were already testing and preparing for production migration or even running in production already on top of 4.0? Do we need broader agreement for this change?
In that sense I personally have the same question as [~aholmber]:
?? Paging ??[~yifanc]?? and ??[~aleksey]?? for their input. I know the microbenchmark showed a great improvement for this encoding in particular, but do we have some idea of how significantly it figures in the overall request execution??
PS In both cases I believe we will need to update the documentation accordingly around UTF8.
was (Author: e.dimitrova):
As someone who was not familiar with the initial work and looks at it with fresh eyes, I have two directions of thinking:
* A group of users who were using UTF8 in previous versions (and I can imagine them not being 1 or 2) observe a breaking change of expected behavior which is not documented.
* We are just before a RC I believe and we promised no breaking changes anymore and now we revert, at least partially, a performance improvement. Then a different part of users gets disappointed as they were already testing and preparing for production migration or even running in production already? Do we need broader agreement for this change?
In that sense I personally have the same question as [~aholmber]:
?? Paging ??[~yifanc]?? and ??[~aleksey]?? for their input. I know the microbenchmark showed a great improvement for this encoding in particular, but do we have some idea of how significantly it figures in the overall request execution??
PS In both cases I believe we will need to update the documentation accordingly around UTF8.
> Fix incorrect encoding for strings can be UTF8
> ----------------------------------------------
>
> Key: CASSANDRA-16429
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16429
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
> Reporter: Yoshi Kimoto
> Assignee: Yifan Cai
> Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: jptest.cql
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Tables created with Japanese character name columns are working well in C* 3.11.10 when doing a SELECT * in cqlsh but will show as garbled (shown as "?") in 4.0-beta4. DESCRIBE shows the column names correctly in both cases.
> Run the attached jptest.cql script in both envs with cqlsh -f. They will yield different results.
> My test env (MacOS 10.15.7):
> C* 3.11.10 with
> - OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_252-b09)
> - Python 2.7.16
> C* 4.0-beta4
> - OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.9.1+1)
> - Python 3.8.2
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org