Basic Principles (Contexts)

A DeveelDB database system is organized in several operative contexts that are important to define the scope of the operations, the lifetime of services and variables, the rights and access to resources.

These contexts have a definite hierarchy, according to the access level in a given operation.

1. System Context
2. Database Context
3. Session/Transaction Context
4. Query Context
5. Code Block Context

The services and variables provided by a given context are inherited by the child contexts, which fallback to the parents when unable to resolve within their own scope.

For example, the definition of a certain service (eg. the SQL Parser) at the System level will be inherited by all the Database levels.

A request for a service made by a context, will instantiate the service in the context's scope, and will dispose this instance when the scope is disposed. This means, for example, that a database-specific service (eg. the storage system of the database) can be registered at system level, but when the single database requests it, an instance of the storage system, specifically configured for the database, is instantiated in the database scope, and disposed when the database is closed (or deleted).

NOTE: when a parent context defines a service statically, by registering an instance of the service (eg. the system functions provider), the call from a child context (eg. the context of a query requesting a single system function) will not dispose the service at the disposal of the context (eg. at the execution of the query, the instance of the system functions provider is not disposed).

The System Context

This is the context where the database system properties, base configurations and services are defined: it is the foundation of every database handled within a system scope.

Properties, configurations and services defined by this context will be inherited by all database contexts, where not overridden (eg. a database-specific configuration, a transaction-specific service, etc.).

The Database Context

Every database created within a system has its own operative context, which inherits configurations and services from the System Context, when not explicitly overridden.

The only required override required in a Database Context is the database name configuration, that is used to uniquely identify the instance of the database within the system.

The database context handles the list of all the open sessions to a database and provides a mechanism for locking resources (eg. tables, views, types, etc.) among transactions, given the isolation level.

Sessions and transactions inherit configurations and services from this context when created.

The Session/Transaction Context

The access to a database is made through isolated transactions, which encapsulate the commands to modify or query resources (see Transactions for more information). A transaction is opened or created for each access session of a user to the database: non-authenticated users have no privileges to access a database (see User Management for more information).

The context of a transaction handles all the services (eg. object managers such as the table manager) and configurations (eg. the isolation level, case sensitivity for the resolution of names, etc.) specific to the scope of a single transaction.

Transactions are the parent for any query context issued during their life-time: they provide queries with the isolated access to the resources. The paired session of a transaction is also providing query contexts with the information about the user owning the transaction, that are used to compute security assessments when trying to access resources.

The Query Context

Transactions to databases can parent multiple queries (commands to modify or read resources), according to their life-time (which ends on a COMMIT or ROLLBACK command).

The most important feature provided in a query context is the assessment of the privileges to access certain resources provided by the parent transaction (eg. when the command requests the access to a certain table of the database, this verifies the user that owns the session has the rights to access it for the operation required).

A query context handles also variables within its scope that can be defined outside code blocks and accessed by other commands.

In this context all the services and configurations inherited from the transaction/session scope cannot be altered (commands to set a certain configuration are passed to the parent transaction context).

The Block Context