[
https://issues.apache.org/jira/browse/CASSANDRA-9148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493822#comment-14493822
]
Benjamin Lerer commented on CASSANDRA-9148:
-------------------------------------------
No problem :-).
Here my remarks:
* The problem with the patch is that it as a side effect. It will announce a
migration for every table that contains a {{UDT}} even if it is not the
modified one.
* I think it is better to use meaningfull name for the unit tests, like
{{testAlteringUserTypeNestedWithinMap}}, as it does not force the reader to go
to internet to understand what the test is about.
* For the tests I would personnally add the following method to {{CQLTester}}:
{code}
protected Object userType(Object...values)
{
return new TupleValue(values).toByteBuffer();
}
{code}
and try to be as precise as possible in the expectations:
{code}
@Test
public void testAlteringUserTypeNestedWithinMap() throws Throwable
{
String ut1 = createType("CREATE TYPE %s (a int)");
createTable("CREATE TABLE %s (x int PRIMARY KEY, y frozen < map < text,
" + KEYSPACE + "." + ut1 + "> >)");
execute("INSERT INTO %s (x, y) VALUES(1, {'firstValue':{a:1}})");
assertRows(execute("SELECT * FROM %s"), row(1, map("firstValue",
userType(1))));
flush();
execute("ALTER TYPE " + KEYSPACE + "." + ut1 + " ADD b int");
execute("INSERT INTO %s (x, y) VALUES(2, {'secondValue':{a:2, b:2}})");
execute("INSERT INTO %s (x, y) VALUES(3, {'thirdValue':{a:3}})");
execute("INSERT INTO %s (x, y) VALUES(4, {'fourthValue':{b:4}})");
assertRows(execute("SELECT * FROM %s"),
row(1, map("firstValue", userType(1))),
row(2, map("secondValue", userType(2, 2))),
row(3, map("thirdValue", userType(3, null))),
row(4, map("fourthValue", userType(null, 4))));
flush();
assertRows(execute("SELECT * FROM %s"),
row(1, map("firstValue", userType(1))),
row(2, map("secondValue", userType(2, 2))),
row(3, map("thirdValue", userType(3, null))),
row(4, map("fourthValue", userType(null, 4))));
}
{code}
By forcing the flush of the data you also make sure that everything work the
same when the data are read from the SSTables.
* I noticed that the unit tests are a bit limited. It would be nice if you
could add some tests for verifying the behavior when the {{UDT}} is nested
within a {{Map}} as a key or within a {{List}}, a {{Set}}, a {{Tuple}} or
another {{UDT}}.
> Issue when modifying UDT
> ------------------------
>
> Key: CASSANDRA-9148
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9148
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Oskar Kjellin
> Assignee: Jeff Jirsa
> Fix For: 2.1.5
>
> Attachments: 9148.txt
>
>
> I'm trying out the user defined types but ran into some issues when adding a
> column to an existing type.
> Unfortunately I had to scrap the entire cluster so I cannot access it any
> more.
> After creating the UDT i adde two tables using it. 1 was just using
> frozen<type>. The other was using both frozen<type> frozen map<String, type>.
> Then I realized I needed to add a new field to the user type. Then when I
> tried to put to any of the two tables (setting all fields to the UDT in the
> datastax java driver) I got this error message that I could not find anywhere
> else but in the cassandra code:
> com.datastax.driver.core.exceptions.InvalidQueryException: Invalid remaining
> data after end of UDT value
> I had to scrap my keyspace in order to be able to use it again. Could not
> even drop one of the tables.
> I know that they are frozen so we cannot modify the value of individual
> fields once they are written but we must be able to modify the schema right?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
