Feature: Support for multiple namespaces about skytable HOT 5 CLOSED

@stellaroid remind

from skytable.

And a design decision has (almost) been made. [draft]

Structure

Why this structure?

1. It allows different sharding strategies on different keyspaces; we can have a system keyspace which cannot be altered by standard users (more on that later) and this will enable us to replicate or toss around critical system information than raw wiring it
2. More logical for our users
3. Multi-table configurations, per-keyspace configuration
4. Helpful for people just coming from SQL backgrounds

Connections

Whenever a database connection will be made to a database instance, they'll be connected to a keyspace called default and a table called default under it. The former is a non-removable keyspace, and the latter is a non-removable table. Keyspaces/namespaces are also connection-level, that is once a keyspace is set, it is global for the connection and not interchangeable. While that doesn't apply for tables which can be switched for different queries.

Unresolved questions

Some questions still remain: is a keyspace abstraction that necessary? Can't we operate on some kind of special table for system critical data that can't be modified externally. I welcome any kind of discussion regarding this

from skytable.

@stellaroid untask

from skytable.

The original comment has been updated, please check

from skytable.

This issue is terribly outdated. A new one will be created and hence this is being closed

from skytable.