Containers

Containers are objects that hold other objects. In Skytable, we have two kinds of containers:

  • Keyspaces: Keyspaces are containers that hold tables. The basic idea is to keep all the related tables for a given application in one logical collection.
  • Tables: Tables are not tables. Funny, isn’t it? Instead, tables are structures that contain the actual data. Be it key/value or the future data models — it’s all in a table

To interact with containers, we need to use DDL actions like CREATE, DROP and INSPECT.

Entities

Every container is an entity. A keyspace being a top-level entity and a table being a low-level entity. Hence a keyspace name or a table name can be called an entity or entity name.

Naming rules

All entity names have the following naming rules:

  • Names are case sensitive
  • Names must begin with an ASCII alphabet (A-Z or a-z) or an underscore (_)
  • Names must be lesser than or equal to 64 characters long
  • Names must not begin with a digit (0-9)
  • Names can contain digits anywhere else (except for the first character)

Entity groups

The most important thing is an Entity Group which is also known as Fully Qualified Entity Syntax (FQE Syntax). FQE syntax is used to describe the full path to a table. For example, if you have a keyspace supercyan and you have a table cyan within it, then the FQE syntax will be:

  1. supercyan:cyan

This can be extremely helpful when running DDL queries.

Important note

When you connect to Skytable, you are connected to the default keyspace which has a default table. The default table or the default keyspace cannot be dropped. There is another keyspace called the system keyspace which is not user-accessible and hence cannot be modified or dropped.

Keyspaces

Like we noted above, keyspaces are logical collections of tables and is known as a top level container. Creating a keyspace is as simple as:

  1. CREATE KEYSPACE <name>

while you can drop keyspaces by running:

  1. DROP KEYSPACE <name>

Note: Keyspaces can only be dropped if no other client is connected to it and if it contains no tables. This can be evaded by forcing removal through other DDL actions.

Tables

Tables contain your actual data: be it key/value, or anything else. Tables reside within keyspaces. To create a table, you’ll need to run:

  1. CREATE TABLE <entity> <model>(modelargs) <properties>

Properties

A table, apart from the data model’s own properties, has some model-indpendent properties. Supplying these are optional. The user-accessible property that you should know about is the volatile property.

The volatile property

Adding the volatile property after your model arguments makes your table volatile. This means that the table itself will exist, but none of its data will persist after a restart. This makes volatile tables extremely useful for caching.

Don’t worry too much about the model and modelargs now — the next section will tell you about models.

Table models

Just jump to the models section

Models

A model defines what kind of data is stored in a table. You can think of it to be a type in a programming language.

The keymap model

A keymap model is the one you just interacted with in the earlier documents. A keymap is like an associated array: it maps a key to a value. More importantly, it maps a specific key type to a specific value type.

Warning: Everything after CREATE TABLE is case sensitive!

This is how you create keymap tables:

  1. CREATE TABLE <entity> keymap(<type>,<type>) <properties>

Here:

  • <entity>: is your table name (or the FQE syntax for your table)
  • <type>: is the data type
  • <properties>: are the optional properties discussed earlier

Data types

The keymap model supports the following types:

  • str: A valid unicode string
  • binstr: A binary string
  • list: A collection type similar to a resizeable array

(more types are expected to be shipped in future editions)

Example

  1. Let’s create a keymap table with an str type key and binstr type value. We’ll assume you’ll be creating it in the default keyspace with the name “mytbl”, so there’s no need to specify an FQE.

    1. CREATE TABLE mytbl keymap(str,binstr)

  2. Let’s create a keymap table with an str type key and a list of binary strings as the value type. Again, we’ll assume you’re in the default keyspace, and we’ll call this table mylist.

    1. CREATE TABLE mylist keymap(str,list<binstr>)

Models in the future

With our goal to build a native multi-model database — we’re working on several data models! All you need to do is hang around in our communities to know what is brewing!

Check out the DDL examples here