[client-v2] Enum label parsing: backslash escapes in a type name are decoded by dropping the backslash, so labels with a newline, tab or NUL are wrong

Ouverte
#3,348 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
Une demi-journée
Accessibilité débutants
64/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
java
Domaine
databases

Piste de recherche

Start in ClickHouseUtils.unescape (clickhouse-data/src/main/java/com/clickhouse/data/ClickHouseUtils.java, around line 511), which ClickHouseEnum uses to decode Enum8/Enum16 labels from type strings. Replace the drop-the-backslash rule with the server's escape mapping, keeping unknown escapes intact and not consuming digits after \0. Run the existing ClickHouseUtilsTest and ClickHouseColumnTest, plus the issue's parser examples such as Enum8('a\nb' = 1) expecting label a LF b. Done when those examples decode correctly and the existing tests still pass.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Describe the bug

ClickHouseUtils.unescape (clickhouse-data/src/main/java/com/clickhouse/data/ClickHouseUtils.java:511-540) is used by ClickHouseEnum to decode Enum8 / Enum16 labels out of a type string (ClickHouseEnum.java:46). It does not implement the server's string-literal escape rules: for any backslash-X sequence it simply drops the backslash and keeps X.

The server writes control characters in a type name as C-style escapes. SELECT toTypeName(CAST(1 AS Enum8('a\nb' = 1))) returns the type string Enum8('a\nb' = 1) where \n is backslash + n, and the real label is a LF b. The client decodes that to the 3-character string anb.

So for every enum label that contains a control character, the client silently returns a label that is different from the one the server stores, and an insert with the correct label throws because the label is not in the map.

What is right and what is wrong today, for the type strings the server itself emits:

Type string from the server Server label (hex) Client label (hex)
Enum8('a\nb' = 1) 610A62 616E62 (anb) wrong
Enum8('a\tb' = 1) 610962 617462 (atb) wrong
Enum8('a\0b' = 1) 610062 613062 (a0b) wrong
Enum8('a\\zb' = 1) 615C7A62 (a\zb) 615C7A62 ok
Enum8('it\'s' = 1) 69742773 (it's) 69742773 ok

Only the doubled backslash and the escaped quote happen to come out right, because for those two the server rule and "drop the backslash" agree. \a, \b, \e, \f, \n, \r, \t, \v, \0, \xHH are all decoded wrong, and an escape the server keeps verbatim loses its backslash.

The same decoder is on both sides of the round trip, so getEnumConstants().value("a\nb") (the insert path, SerializerUtils.java:865) also fails for a label the server really has.

This is the Java counterpart of ClickHouse/clickhouse-cs#729 (that client uses .NET Regex.Unescape, a different wrong rule with a partly different symptom set).

ClickHouse server version

26.10.3.7, verified against a running server.

Reproduction

End-to-end, client-v2 over HTTP (TestNG, client-v2/src/test/java/...):

package com.clickhouse.client;

import com.clickhouse.client.api.Client;
import com.clickhouse.client.api.query.GenericRecord;
import org.testng.Assert;
import org.testng.annotations.Test;

import java.util.List;

public class EnumEscapeTest {
    private static String hex(String s) {
        StringBuilder sb = new StringBuilder();
        for (char c : s.toCharArray()) {
            sb.append(String.format("%02X", (int) c));
        }
        return sb.toString();
    }

    @Test(groups = { "unit" })
    public void testEnumLabelWithNewline() throws Exception {
        try (Client client = new Client.Builder()
                .addEndpoint("http://localhost:8123")
                .setUsername("default").setPassword("")
                .compressServerResponse(false)
                .build()) {
            client.execute("DROP TABLE IF EXISTS scratch_enum_nl").get();
            client.execute("CREATE TABLE scratch_enum_nl (e Enum8('a\\nb' = 1)) ENGINE = Memory").get();
            client.execute("INSERT INTO scratch_enum_nl VALUES (1)").get();

            List<GenericRecord> serverSide = client.queryAll("SELECT hex(toString(e)) AS h FROM scratch_enum_nl");
            String serverHex = serverSide.get(0).getString("h");

            List<GenericRecord> clientSide = client.queryAll("SELECT e FROM scratch_enum_nl");
            String clientLabel = clientSide.get(0).getString("e");

            Assert.assertEquals(hex(clientLabel), serverHex);
        }
    }
}

Result:

java.lang.AssertionError: expected [610A62] but found [616E62]

Expected 610A62 (a, LF, b) — what the server stores. Actual 616E62 (anb).

Parser-level, no server needed (clickhouse-data, these are the exact type strings toTypeName() returns):

ClickHouseColumn.of("e", "Enum8('a\\nb' = 1)").getEnumConstants().name(1);   // "anb",  expected "a\nb"
ClickHouseColumn.of("e", "Enum8('a\\tb' = 1)").getEnumConstants().name(1);   // "atb",  expected "a\tb"
ClickHouseColumn.of("e", "Enum8('a\\0b' = 1)").getEnumConstants().name(1);   // "a0b",  expected "a\0b"
ClickHouseColumn.of("e", "Enum8('a\\\\zb' = 1)").getEnumConstants().name(1); // "a\\zb", ok
ClickHouseColumn.of("e", "Enum8('it\\'s' = 1)").getEnumConstants().name(1);  // "it's",  ok
Suggested fix

In ClickHouseUtils.unescape (clickhouse-data/src/main/java/com/clickhouse/data/ClickHouseUtils.java:511), decode with the server's rules instead of unconditionally dropping the backslash:

  • a doubled quote is one quote (already correct);
  • \a, \b, \e, \f, \n, \r, \t, \v, \0, doubled backslash, escaped quotes and backtick, and \xHH map to their byte values;
  • any other escape keeps the backslash (\z stays \z);
  • \0 never consumes the digits that follow it (\012 is NUL then 12).

unescape is also reached from ClickHouseUtils.readValueArray (ClickHouseUtils.java:1449), so any change there should be checked against the existing ClickHouseUtilsTest / ClickHouseColumnTest cases.

Link

Counterpart issue in the .NET client: https://github.com/ClickHouse/clickhouse-cs/issues/729

Langage dominant
Java
Étoiles
1.6k
Forks
649
Merge moyen
1 j 20 h
PR mergées (30 j)
39

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de ClickHouse/clickhouse-java

Toutes les issues de ClickHouse/clickhouse-java

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.