Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 13 Feb 2015 19:44:12 +0000 (UTC)
From: "Tyler Hobbs (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12774017.1423610327000.42375.1423856652767@Atlassian.JIRA>
In-Reply-To: <JIRA.12774017.1423610327000@Atlassian.JIRA>
References: <JIRA.12774017.1423610327000@Atlassian.JIRA>
 <JIRA.12774017.1423610327236@arcas>
Subject: [jira] [Commented] (CASSANDRA-8779) Able to unintentionally nest
 tuples during insert
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CASSANDRA-8779?page=3Dcom.atlas=
sian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D=
14320643#comment-14320643 ]=20

Tyler Hobbs commented on CASSANDRA-8779:
----------------------------------------

So here's what's happening:

The driver serializes the tuple as {{\x00\x01\x00\x00\x00\x13\x00\x00\x00\x=
03foo\x00\x00\x00\b\x00\x00\x00\x00\x00\x00\x00\{}}.  The leading {{\x00\x0=
1}} is the number of arguments (1), and then the {{\x00\x00\x00\13}} is the=
 length of the first (and only) argument.

Cassandra is expecting an AsciiType argument, so it reads the length (16 by=
tes) and then interprets the rest of the bytes as the string.  Since tuples=
 can omit elements at the end of the tuple, the other elements end up as nu=
ll.

Part of the reason this isn't caught on either end is because it's a Query =
message with attached binary query parameters, instead of an Execute messag=
e (for a prepared statement) or a Query with parameters already integrated =
into the query string.  So, the driver doesn't know what type it should be =
targeting.  It's guessing based on the query parameter type (the Ruby or Ja=
va type).  Cassandra does know what type it's expecting, but the serializat=
ion format doesn't include type information, so as long as the parameters c=
an be validated/interpreted as the expected type, there won't be an error.

One reasonable way to prevent this sort of error would be to include the ty=
pecode alongside the serialized query parameter.  The drivers would set tha=
t typecode to whatever type they're serializing the data as.  Server-side, =
Cassandra would validate that the typecode matches the expected type.

We could only require this for Query messages with attached parameters (sin=
ce drivers can enforce types for Execute messages), or we could be extra sa=
fe and require it for Execute messages as well (which might be overkill).

[~slebresne] what do you think about the above suggestion?

> Able to unintentionally nest tuples during insert
> -------------------------------------------------
>
>                 Key: CASSANDRA-8779
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8779
>             Project: Cassandra
>          Issue Type: Bug
>         Environment: Linux Mint 64-bit | ruby-driver 2.1 | java-driver 2.=
1 | C* 2.1.2
>            Reporter: Kishan Karunaratne
>            Assignee: Tyler Hobbs
>
> If I insert a tuple using an extra pair of ()'s, C* will let me do the in=
sert, but (incorrectly) creates a nested tuple as the first tuple value. Up=
on doing a select statement, the result is jumbled and has weird binary in =
it (which I wasn't able to copy into here).
> Example using ruby-driver:
> {noformat}
> session.execute("CREATE TABLE mytable (a int PRIMARY KEY, b frozen<tuple<=
ascii, bigint, boolean>>)")
> complete =3D Cassandra::Tuple.new('foo', 123, true)
> session.execute("INSERT INTO mytable (a, b) VALUES (0, (?))", arguments: =
[complete])            # extra ()'s here
> result =3D session.execute("SELECT b FROM mytable WHERE a=3D0").first
> p result['b']
> {noformat}
> Output:
> {noformat}
> #<Cassandra::Tuple:0x97b328 (=03fo{=01=01, , )>
> {noformat}
> Bug also confirmed using java-driver.=20
> Example using java-driver:
> {noformat}
> session.execute("CREATE TABLE mytable (a int PRIMARY KEY, b frozen<tuple<=
ascii, int, boolean>>)");
> TupleType t =3D TupleType.of(DataType.ascii(), DataType.cint(), DataType.=
cboolean());
> TupleValue complete =3D t.newValue("foo", 123, true);
> session.execute("INSERT INTO mytable (a, b) VALUES (0, (?))", complete); =
// extra ()'s here
> TupleValue r =3D session.execute("SELECT b FROM mytable WHERE a=3D0").one=
().getTupleValue("b");
> System.out.println(r);
> {noformat}
> Output:
> {noformat}
> ('=03foo=04{=01=01', null, null)
> {noformat}


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)