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.

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:

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 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.

    while you can drop keyspaces by running:

    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>

    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.

    Just jump to

    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.

    Warning: Everything after CREATE TABLE is case sensitive!

    This is how you create keymap tables:

    Here:

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

    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)

    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!