Was this page helpful?
ScyllaDB Java Driver is available under the Apache v2 License. ScyllaDB Java Driver is a fork of DataStax Java Driver. See Copyright here.
Caution
You're viewing documentation for a previous version of Scylla Java Driver. Switch to the latest stable version.
Relations¶
A relation is a clause that appears after the WHERE keyword, and restricts the rows that the statement operates on.
Relations are used by the following statements:
The easiest way to add a relation is with a whereXxx method in the fluent API:
selectFrom("sensor_data").all()
.whereColumn("id").isEqualTo(bindMarker())
.whereColumn("date").isGreaterThan(bindMarker());
// SELECT * FROM sensor_data WHERE id=? AND date>?
You can also create it manually with one of the factory methods in Relation, and then pass it to
where():
selectFrom("user").all().where(
Relation.column("id").isEqualTo(bindMarker()));
// SELECT * FROM user WHERE id=?
If you call where() multiple times, the clauses will be joined with the AND keyword. You can also
add multiple relations in a single call. This is a bit more efficient since it creates less
temporary objects:
selectFrom("sensor_data").all()
.where(
Relation.column("id").isEqualTo(bindMarker()),
Relation.column("date").isGreaterThan(bindMarker()));
// SELECT * FROM sensor_data WHERE id=? AND date>?
Relations are generally composed of a left operand, an operator, and an optional right-hand-side term. The type of relation determines which operators are available.
Simple columns¶
whereColumn operates on a single column. It supports basic arithmetic comparison operators:
| Comparison operator | Method name |
|---|---|
= |
isEqualTo |
< |
isLessThan |
<= |
isLessThanOrEqualTo |
> |
isGreaterThan |
>= |
isGreaterThanOrEqualTo |
!= |
isNotEqualTo |
Note: we support != because it is present in the CQL grammar but, as of Cassandra 4, it is not
implemented yet.
See above for comparison operator examples.
If you’re using SASI indices, you can also use like() for wildcard comparisons:
selectFrom("user").all().whereColumn("last_name").like(literal("M%"));
// SELECT * FROM user WHERE last_name LIKE 'M%'
in() is like isEqualTo(), but with various alternatives. You can either provide each alternative as a
term:
selectFrom("user").all().whereColumn("id").in(literal(1), literal(2), literal(3));
// SELECT * FROM user WHERE id IN (1,2,3)
selectFrom("user").all().whereColumn("id").in(bindMarker(), bindMarker(), bindMarker());
// SELECT * FROM user WHERE id IN (?,?,?)
Or bind the whole list of alternatives as a single variable:
selectFrom("user").all().whereColumn("id").in(bindMarker());
// SELECT * FROM user WHERE id IN ?
For collection columns, you can check for the presence of an element with contains() and
containsKey():
selectFrom("sensor_data")
.all()
.whereColumn("id").isEqualTo(bindMarker())
.whereColumn("date").isEqualTo(bindMarker())
.whereColumn("readings").containsKey(literal("temperature"))
.allowFiltering();
// SELECT * FROM sensor_data WHERE id=? AND date=? AND readings CONTAINS KEY 'temperature' ALLOW FILTERING
Finally, isNotNull() generates an IS NOT NULL check. Note: we support IS NOT NULL because it
is present in the CQL grammar but, as of Cassandra 4, it is not implemented yet.
Column components¶
whereMapValue operates on an value inside of a map:
selectFrom("sensor_data")
.all()
.whereColumn("id").isEqualTo(bindMarker())
.whereColumn("date").isEqualTo(bindMarker())
.whereMapValue("readings", literal("temperature")).isGreaterThan(literal(65))
.allowFiltering();
// SELECT * FROM sensor_data WHERE id=? AND date=? AND readings['temperature']>65 ALLOW FILTERING
Column components support the six basic arithmetic comparison operators.
Tokens¶
whereToken hashes one or more columns into a token. It is generally used to perform range queries:
selectFrom("user")
.all()
.whereToken("id").isGreaterThan(bindMarker())
.whereToken("id").isLessThanOrEqualTo(bindMarker());
// SELECT * FROM user WHERE token(id)>? AND token(id)<=?
It supports the six basic arithmetic comparison operators.
Multi-column relations¶
whereColumns compares a set of columns to tuple terms of the same arity. It supports the six basic
arithmetic comparison operators (using lexicographical order):
selectFrom("sensor_data")
.all()
.whereColumn("id").isEqualTo(bindMarker())
.whereColumns("date", "hour").isGreaterThan(tuple(bindMarker(), bindMarker()));
// SELECT * FROM sensor_data WHERE id=? AND (date,hour)>(?,?)
In addition, tuples support the in() operator. Like with regular columns, bind markers can operate
at different levels:
// Bind the whole list of alternatives (two-element tuples) as a single value:
selectFrom("test")
.all()
.whereColumn("k").isEqualTo(literal(1))
.whereColumns("c1", "c2").in(bindMarker());
// SELECT * FROM test WHERE k=1 AND (c1,c2) IN ?
// Bind each alternative as a value:
selectFrom("test")
.all()
.whereColumn("k").isEqualTo(literal(1))
.whereColumns("c1", "c2").in(bindMarker(), bindMarker(), bindMarker());
// SELECT * FROM test WHERE k=1 AND (c1,c2) IN (?,?,?)
// Bind each element in the alternatives as a value:
selectFrom("test")
.all()
.whereColumn("k").isEqualTo(literal(1))
.whereColumns("c1", "c2").in(
tuple(bindMarker(), bindMarker()),
tuple(bindMarker(), bindMarker()),
tuple(bindMarker(), bindMarker()));
// SELECT * FROM test WHERE k=1 AND (c1,c2) IN ((?,?),(?,?),(?,?))
Custom index expressions¶
whereCustomIndex evaluates a custom index. The argument is a free-form term (what is a legal value
depends on your index implementation):
selectFrom("foo")
.all()
.whereColumn("k").isEqualTo(literal(1))
.whereCustomIndex("my_custom_index", literal("a text expression"));
// SELECT * FROM foo WHERE k=1 AND expr(my_custom_index,'a text expression')
Raw snippets¶
Finally, it is possible to provide a raw CQL snippet with whereRaw(); it will get appended to the
query as-is, without any syntax checking or escaping:
selectFrom("foo").all().whereRaw("k = 1 /*some custom comment*/ AND c<2");
// SELECT * FROM foo WHERE k = 1 /*some custom comment*/ AND c<2
This should be used with caution, as it’s possible to generate invalid CQL that will fail at execution time; on the other hand, it can be used as a workaround to handle new CQL features that are not yet covered by the query builder.