Creating and Altering RootDB Databases

Creating a New RootDB Database

Java classes (POJO) and a property file that define the target database product

The structure of the new RootDB database is defined using Java (POJO) classes.

If indexing is required to enhance database search performance, the @Index annotation can be used in conjunction with Java classes to define indexes. Both unique and non-unique indexes are supported for keys that consist of one or more fields. As with all databases, indexing increases the database size and can reduce performance when maintaining data. However, indexing can often be omitted for RootDB object databases, as their queries are highly efficient even without indexing.

A YAML (.yaml) properties file is required to define the target database product, which serves as a platform for storing and processing objects as an object database. Nearly all database products are suitable for use as a platform for object databases, with the primary requirement being that the database product supports transactions. Relational databases with SQL are excellent platforms, but many other databases, even those without a formal schema or SQL support, can also serve as highly effective and efficient platforms.

At present, the supported databases are MariaDB and JetBrains Xodus. MariaDB is a relational database that uses the SQL command language, while JetBrains Xodus is a key-value pair database that operates without a formal database schema.

Once the Java classes for the object model have been written and the YAML (.yaml) properties file for the database product has been defined, a new object database can be created from the command line. The resulting object database and its object model form a tightly integrated combination, ensuring that the database cannot be accidentally used with a different object model.

Altering an Existing RootDB Database

New Java (POJO) classes to extend the object model and a text file (.rql) containing the alter commands

When introducing the concept of object databases as a replacement for relational databases to database experts, the most common reaction is the concern that object databases lack the ability to modify their structure, preventing widespread adoption. This has indeed been the prevailing limitation, which is quite peculiar given the rapid advancements in computer science over the past 50 years. However, this limitation is not due to a lack of effort, as many competent actors with substantial resources have attempted to develop object databases, but none have succeeded in solving the complex challenges inherent to to object databases.

The simple, yet somewhat perplexing truth is that enabling structural changes in object databases is just a damn hard nut to crack. Finding a general and clear solution, along with the necessary methods (algorithms), is extremely difficult when both the Java object model and traditional databases (such as relational databases) are designed for entirely different purposes. While both have their merits, they offer little help in solving this particular problem. This challenge has been the primary bottleneck and even a significant obstacle in the development of RootDB. In fact, the active phase of researching and conceptualizing a solution took several years.

The SQL command language used in relational databases includes several commands for modifying the database structure (schema). The schema is made up of tables that can be added, modified, or deleted using the SQL commands CREATE, ALTER and DROP. These commands allow changes to be made to the schema of a database that already contains data, which is essential because, without this capability, the entire database would need to be recreated from scratch.

In object databases, this approach is not feasible because the database and its persistent storage structure are not known to the programmer. In other words, there is no such database structure (schema) where a programmer could apply commands similar to SQL. The database structure is entirely managed by the object database system, which is why the programmer cannot modify it directly, as would be possible with SQL in relational databases.

The structure of a RootDB object database is defined by Java classes, which collectively form the object model of the database. When changes to the database structure are required, these modifications are not made directly to the persistent database structure, but rather through the object model. The object model, composed of Java classes, and the commands that modify it must process both the Java source code and the corresponding structures in the persistent database. One of the key challenges is managing both the old version (before changes) and the new version (after changes), as both versions are involved as compiled and loaded classes during this process.

While the algorithms and implementation pose a significant challenge, defining a proper and sufficient set of commands to modify the object model is relatively straightforward, as Java classes have a well-defined structure. Java classes consist of fields, with reference fields playing a special role since they define relationships to other classes, including recursion. Class inheritance is another relationship that requires its own commands. Additionally, changes to the indexing of object fields in the database must also be supported. To address these needs, RQL provides 8 add and 8 delete commands that can modify the object model and its persistent structure in the object database. These commands are, in principle, capable of transforming any object model (data structure) into another. Importantly, these commands can be applied to object databases that already contain data in the form of objects.

In practice, RQL commands are written into a text file and executed using the rdbmake tool, which is part of the RootDB system. Similar to how SQL command files use the '.sql' extension, RQL command files use the '.rql' extension. The RQL commands in the file (.rql) are executed sequentially, line by line, from the beginning to the end of the file.

As described above, the RQL commands for modifying the object model (8 add and 8 delete commands) are fairly straightforward since they are based on the structure of Java classes and their properties. It must be possible to add new Java classes to the object model and naturally also delete old ones, although inheritance introduces additional requirements. Fields in Java classes fall into four categories: atomic values, arrays of atomic values, single reference fields, and reference list fields. Add and delete commands are required for each of these categories. Additionally, commands are needed to add and delete indexes consisting of one or more fields.

With the RQL add and delete commands, maintaining object databases is now much simpler and more efficient than traditional relational databases. All commands fully adhere to the principles and practices of object-oriented programming (OOP). When programming databases, there is no longer a need to master the specific features of any particular database product, nor is there a need for the SQL command language. As a result, programmers no longer need to optimize SQL statements for individual databases, and the database structure (schema) itself is abstracted from the programmer. All database tasks can now be programmed using the RQL command language, offering a modern programming model (OOP) and enhanced efficiency.

Unfortunately, we are unable to provide actual examples on this site, as doing so would disclose too much about this unreleased technology.