Basic concepts

The basic idea is that you store your data inside objects and link it by using link attributes.

Every object has one or more classes (defined with the Data Type Definition Language, or DTDL). A class only exists if it is referenced by another object or as part of a named object. An object only exists if it contains at least one referenced class.

Every object has an ID. Those IDs are guaranteed to be unique inside the domain.

An application normally starts its navigation with a named object. These are objects that can be found by their named object GUID. Those named objects are, in most cases, built during setup.

From this point, the application can follow the path to the data it is interested in. If you have, for example, a named object called 'contracts', you first open the contracts object. Then, via the 'currentcontracts' attribute, you can find a list of all the current contracts. When you have found the contract, you can open it and find its owner via its 'owner' attribute. Inside the next object, you might have a link to the 'address' object, and so on.

The navigation relies on those links an application creates. It is a very natural way of working with data and data links, and it therefore allows you to build and model data without any transformation from the real world. You simply do, think and work as always.

Because of its special linking feature, DataFS provides an easy way of accessing data from different paths. There is no need to build a tree or to decide whether to store data in one place or another. Data seems to exist in multiple places at the same time.

One of the main ideas of DataFS is that every object cannot just exist in multiple places; instead, it can also be different types of objects at the same time. Because every object can have many classes at the same time, it can contain different pieces of information (e.g. a contract, notes, car information and hotel room status) at the same time. This provides outstanding flexibility for data modeling.

Every operation on the database is part of a 'transaction' or 'action group'. Action groups can contain write and read operations. When an action group is being executed, the system executes all the write operations first of all, then all the read operations. All the write operations are executed as one atomic operation, then all the read operations are executed as one atomic operation. 'Atomic operation' means that the system executes everything or nothing, all at the exact same time. The read operations are always executed after the write operations. You should not expect them to be executed at the same time as the write operations.