mirror of https://github.com/apache/cassandra
The length of table names was not controlled. This is likely due to confusion between validation methods with similar names. As result creating tables with too long names led to the too long file name exceptions during table creations. This commit adds a validation of table name lengths to avoid the too long file name errors. The validation length is based on how the table name is used to create file/directory names, and needs to be exact to prevent the too long file name exception, but allow all other table names, which didn't lead to the too long file name exception. This length limit is different from the existing name length limit of 48 characters used by common validation functions. Thus, this commit moves out the length validation from the validation methods into a separate length validation method, so the errors on names are more specific. The non-length validation methods combined into a single method, which checks for empty names and valid characters. New constants are added for the length limits. Table name related code are moved into methods in TableMetadata class, so their semantics are more clear and to allow reuse, e.g., in asserting the table name length constant. Tests are added for the long table names and non-alphanumeric names. Keyspace name validation function is now shared between two classes and a unit test of it is added. Patch by Ruslan Fomkin; reviewed by Piotr Kołaczkowski, Dmitry Konstantinov, Maxwell Guo for CASSANDRA-20389 |
||
|---|---|---|
| .build | ||
| .circleci | ||
| .jenkins | ||
| bin | ||
| conf | ||
| debian | ||
| doc | ||
| examples/triggers | ||
| ide | ||
| lib | ||
| pylib | ||
| redhat | ||
| src | ||
| test | ||
| tools | ||
| .gitignore | ||
| .snyk | ||
| CASSANDRA-14092.txt | ||
| CHANGES.txt | ||
| CONTRIBUTING.md | ||
| LICENSE.txt | ||
| NEWS.txt | ||
| NOTICE.txt | ||
| README.asc | ||
| TESTING.md | ||
| build-shaded-dtest-jar.sh | ||
| build.properties.default | ||
| build.xml | ||
| eclipse_compiler.properties | ||
| relocate-dependencies.pom | ||
README.asc
Apache Cassandra
-----------------
Apache Cassandra is a highly-scalable partitioned row store. Rows are organized into tables with a required primary key.
https://cwiki.apache.org/confluence/display/CASSANDRA2/Partitioners[Partitioning] means that Cassandra can distribute your data across multiple machines in an application-transparent matter. Cassandra will automatically repartition as machines are added and removed from the cluster.
https://cwiki.apache.org/confluence/display/CASSANDRA2/DataModel[Row store] means that like relational databases, Cassandra organizes data by rows and columns. The Cassandra Query Language (CQL) is a close relative of SQL.
For more information, see http://cassandra.apache.org/[the Apache Cassandra web site].
Requirements
------------
. Java >= 1.8 (OpenJDK and Oracle JVMS have been tested)
. Python 3.6+ (for cqlsh; 2.7 works but is deprecated)
Getting started
---------------
This short guide will walk you through getting a basic one node cluster up
and running, and demonstrate some simple reads and writes. For a more-complete guide, please see the Apache Cassandra website's http://cassandra.apache.org/doc/latest/getting_started/[Getting Started Guide].
First, we'll unpack our archive:
$ tar -zxvf apache-cassandra-$VERSION.tar.gz
$ cd apache-cassandra-$VERSION
After that we start the server. Running the startup script with the -f argument will cause
Cassandra to remain in the foreground and log to standard out; it can be stopped with ctrl-C.
$ bin/cassandra -f
Now let's try to read and write some data using the Cassandra Query Language:
$ bin/cqlsh
The command line client is interactive so if everything worked you should
be sitting in front of a prompt:
----
Connected to Test Cluster at localhost:9160.
[cqlsh 2.2.0 | Cassandra 1.2.0 | CQL spec 3.0.0 | Thrift protocol 19.35.0]
Use HELP for help.
cqlsh>
----
As the banner says, you can use 'help;' or '?' to see what CQL has to
offer, and 'quit;' or 'exit;' when you've had enough fun. But lets try
something slightly more interesting:
----
cqlsh> CREATE KEYSPACE schema1
WITH replication = { 'class' : 'SimpleStrategy', 'replication_factor' : 1 };
cqlsh> USE schema1;
cqlsh:Schema1> CREATE TABLE users (
user_id varchar PRIMARY KEY,
first varchar,
last varchar,
age int
);
cqlsh:Schema1> INSERT INTO users (user_id, first, last, age)
VALUES ('jsmith', 'John', 'Smith', 42);
cqlsh:Schema1> SELECT * FROM users;
user_id | age | first | last
---------+-----+-------+-------
jsmith | 42 | john | smith
cqlsh:Schema1>
----
If your session looks similar to what's above, congrats, your single node
cluster is operational!
For more on what commands are supported by CQL, see
https://cassandra.apache.org/doc/4.0/cassandra/cql/[the CQL reference]. A
reasonable way to think of it is as, "SQL minus joins and subqueries, plus collections."
Wondering where to go from here?
* Join us in #cassandra on the https://s.apache.org/slack-invite[ASF Slack] and ask questions
* Subscribe to the Users mailing list by sending a mail to
user-subscribe@cassandra.apache.org
* Visit the http://cassandra.apache.org/community/[community section] of the Cassandra website for more information on getting involved.
* Visit the http://cassandra.apache.org/doc/latest/development/index.html[development section] of the Cassandra website for more information on how to contribute.