cassandra - que - cql examples
Actualizar una columna en Cassandra en función de Where Clause (3)
Tengo una mesa muy simple
cqlsh:hell> describe columnfamily info ;
CREATE TABLE info (
nos int,
value map<text, text>,
PRIMARY KEY (nos)
)
La siguiente es la consulta en la que intento actualizar el valor.
update info set value = {''count'' : ''0'' , ''onget'' : ''function onget(value,count) { count++ ; return {"value": value, "count":count} ; }'' } where nos <= 1000 ;
Bad Request: Invalid operator LTE for PRIMARY KEY part nos
Yo uso cualquier operador para especificar la restricción. Se queja diciendo que el operador no es válido. No estoy seguro de lo que estoy haciendo mal aquí, de acuerdo con cassandra 3.0 cql doc, hay consultas de actualización similares.
La siguiente es mi versión
[cqlsh 4.1.0 | Cassandra 2.0.3 | CQL spec 3.1.1 | Thrift protocol 19.38.0]
No tengo idea, ¿qué está mal?
Actualmente, Cassandra no admite funciones definidas por el usuario dentro de una consulta como la siguiente.
update info set value = {''count'' : ''0'' , ''onget'' : ''function onget(value,count) { count++ ; return {"value": value, "count":count} ; }'' } where nos <= 1000 ;
Primero, ¿puede insertar esta función onget en la capa de aplicación? Primero puede consultar todas las filas cuyos valores son <1000. Luego, incremente las filas a través de una consulta por lotes.
De lo contrario, puede usar una columna de contador para los nos , no un tipo de datos int. Sin embargo, tenga en cuenta que no puede mezclar el tipo de datos del map con las familias de columna del contador, a menos que las columnas que no sean del contador formen parte de una clave compuesta.
Además, es probable que no desee tener valores, una columna que cambie el valor como la clave principal.
CREATE TABLE info (
id UUID,
value map<text, text>,
PRIMARY KEY (id)
)
CREATE TABLE nos_counter (
info_id UUID,
nos COUNTER,
PRIMARY KEY (info_id)
)
Ahora puedes actualizar el contador de nos como este.
update info set nos = nos + 1 where info_id = ''SOME_UUID'';
La respuesta está realmente en mi comentario, pero necesita un poco de elaboración. Para replantear del comentario ...
El primer predicado de la cláusula where tiene que identificar de manera única la clave de partición. En su caso, dado que la clave principal es solo una columna, la clave de partición == la clave principal.
Cassandra no puede hacer escaneos de rango sobre particiones. En el lenguaje de CQL, una partición es una fila de almacenamiento potencialmente amplia que se identifica de manera única con una clave. En este caso, los valores en su columna nos. Los valores de las claves de partición están codificados en tokens que identifican explícitamente dónde viven esos datos en el clúster. Como ese hash no tiene ningún orden, Cassandra no puede usar otro operador que no sea igualdad para encaminar un enunciado al destino correcto. Este no es un índice de clave principal que podría ser actualizado, es el mecanismo de partición fundamental en Cassandra. Por lo tanto, no puede usar operadores de desigualdad como la primera cláusula de un predicado. Puede utilizarlos en cláusulas posteriores porque la partición se ha identificado y ahora se trata de un conjunto ordenado de columnas.
No puede usar condiciones no iguales en la clave de partición ( nos es su clave de partición).