The Object Database (WODBMS)

The WODBMS acronym means "Wedgefish Object Database Management System".
It is a database abstraction, focusing on types, objects and relationships, allowing features not found in conventional databases, such as content localization and numerically indexed fields.
Even without any SQL language knowledge, it is possible to write code to query the WODBMS and retrieve not only a set of objects based on certain criteria, but also related items field values, packed into a single indexed array or object⁽¹⁾.
The WODBMS is an essential component of Wedgefish, and many of the platform features rely on it, therefore it is always enabled. The logic involved in reading and writing data to the WODBMS, interfacing to a conventional database or other kind of storage, were enclosed in a module, to be able to switch to a different implementation without having to modify the core system⁽²⁾.

By default, Wedgefish has been configured to use the wodbmsmysql module, which implements the WODBMS as an abstraction on a set of MySQL tables. This offers multiple advantages:

• referential integrity (through use of the InnoDB engine)
• extensive use of indexes, to optimize performance
• FULLTEXT index on the localized content table, to ease implementing search engines
• usage of normal tables containing numerical or string values, for fast comparison
• the possibility to run MySQL on a separate server or cluster of replicated servers
• native support of SQL conditions and some other useful SQL functions
  

Future Wedgefish versions will include a wodbmssql module, which will allow using any kind of SQL-based database (such as PostgreSQL and SQLite) as a storage engine for the WODBMS, by calling database access functions from the relevant modules (eg. mysql, postgresql, sqlite).
This architecture would also theoretically help to create a WODBMS implementation totally independent from SQL language (eg. text file based or binary format) although this would involve considerable work.

If needed, other conventional databases can also be used in parallel to the WODBMS, to store and retrieve data in tabular form through normal SQL statements, although many features won't be available with these kinds of databases⁽³⁾.

You'll find below a detailed description of the main fundamental concepts underlying the WODBMS.

Websites

A single WODBMS can theoretically keep data for hundreds of thousands or millions of websites. This is the ideal choice for blog portals or sites collecting personal user pages and profiles (such as social networks), and typically for Application Service Providers hosting small businesses websites that would otherwise require myriads of separate databases, with duplication of functionality and consequent difficulties in managing resources.
Considering its performance, however, the WODBMS is also suitable for single projects with a very large database.
The data integrity is guaranteed, as explained above, by the SQL engine itself.
Another advantage resulting from storing multiple websites data into a single database is the possibility of establishing relations between objects in different sites (which would otherwise be impossible with conventional database), searching for content in a set of websites, and giving rights to display and edit resources from multiple websites to certain users⁽⁴⁾.
If desired, a different WODBMS for each website or sets of websites can also be used instead, by configuring multiple instances of the platform (as separate Apache virtual hosts) using the same codebase, modules and templates (through symbolic links, or duplicating the code) with independent configuration files. However, this shouldn't be needed, because the wodbmsmysql module has been built on an highly optimized SQL database, with extensive use of indexes.

Object Classes

Classes define object properties and their attributes.
You can figure them as the equivalent of conventional database tables, but with many additional features, including:

• the possibility of establishing read and write access rights to lists of users and groups (ACL)
• the possibility to hide classes which items are not modifiable by the currently logged in user
• relationships with other classes (also specifying the related property name in the related class)
• extended attributes available on each class property, in order to facilitate the automatic generation of a graphical dataentry (number of tab, number of row, position in the row, field size, caption, type of graphical representation etc...)

Classes are unique for each website, which makes possible to customize them freely: it is therefore possible, for example, to have specific attributes for users of a particular site to store their preferences and other data, change the attributes of properties (such as their position in the data entry forms), make their items editable only to certain groups of users etc...

Objects (also called Items)

The WODBMS stores every kind of data as items: users, groups of users, website pages, categories, menu, images, articles, comments...
This data uniformity makes possible to apply the same tools (such as listings, the Universal Item Editor, the ACL, the XML export...) to any kind of object, without having to write new code or modify existing one whenever you add a new field, as it would happen with conventional PHP / SQL development.

You may view items as rows of a database, with a variable number of fields. Each item is associated to a class, so they can be easily grouped together with other items of the same type (Users, Web pages etc...) but it is in no way hard-related to it, so that it can be easily transformed into an item of a completely different type, simply switching its class, while values of properties having the same name in the new class will be preserved.
We could for instance turn a Web page into a Section index, or to a comment to another Web page, simply by switching item class and eventually filling in required property values which were missing in the previous class.

Each item can be associated to one or more "web views" which are URL representations of the item content.
A web view is made up by a URL, a view and a controller.
The controller may get the item properties from the WODBMS, and use them to populate the view contents.
This way, you can have multiple URL pointing to the same item content, each one rendered in a different way (by a different view or controller).

Item properties

Each item can have a variable number of properties (also known as variables), which may usually correspond to those defined in its class.
Properties of different types can be defined, some of them correspond to those of a conventional database, while others are completely new. Each type is identified by a letter:

• N - Numeric (a 32-bit signed integer)
• S - String (not-localized content ranging from 1 to 255 characters in length)
• T - Localized text (content which may be up to 16Mb in size, and which may be localized in all languages which had been enabled for the website)
• R - Relationship (identifier of a related item)
• H - Localized HTML (HTML content which may be up to 16Mb in size, and can be localized in all languages which had been enabled for the website; links will be automatically adjusted when retrieving item, to work whichever the page URL)
• E - Email address (format will be enforced when storing it into the WODBMS, and also client-side by the Universal Item Editor)⁽⁵⁾)
• P - Password (only the the md5 hash is stored)
• B - Boolean (true or false, but also YES / NO in several languages, 0 / 1 and everything that can be interpreted in two opposite ways)
• D - Date (in a particular compact format, only including day, month, year, hours and minutes without seconds, allowing representing every year from 0 to 4095 in 32-bit format)
• C - Color (32 bit format with 8 bits for the transparency, 8 bits for red component, 8 bits for the green component and 8 bits for blue component)
• A - IP Address v4 (in xxx.xxx.xxx.xxx format)

There are some string properties which, although not explicitly defined in any class, may be assigned to all kind of objects: META tags. These are automatically inserted in the HEAD section of rendered HTML pages.

An outstanding feature of item properties, which clearly distinguishes them from a conventional database row columns, is their ability to be indexed (if defined as multiple).
We can have, for instance, users with multiple phone numbers, articles with several authors and sources, and a set of keywords (stored in the meta_keyword multiple string variable) associated to a web page, and so on.
Similarly a localized text or HTML content can be translated into several languages, without having to create multiple linked items, but maintaining all translations stored into the same item, facilitating managing other non-localized properties of the same item (such as the price of a product, for instance).
Note: In the MySQL-based WODBMS implementation, each property of an item is stored in a single row of one of four different tables (numeric, string, text or relationship) which is related to the item itself and which is indexed starting from 1. This way, properties are associated with objects with a one-to-many relationship, and the number of indexed elements can be extended indefinitely, something which is simply impossible to obtain with a conventional database, where it would be necessary to create a set of tables for each one-to-many and many-to-many relationship, with lots of efforts and development time needed.

ACL (Access Control Lists)

ACLs are a powerful tool to define, in a completely programming-independent manner, that some items should be displayed and / or modified only by certain groups of users or individual users.
For example, they can be used to restrict access to certain pages to anonymous users, but they may have unlimited uses, such as ensuring that only registered users of certain groups can post comments to a blog posts, upload new photos in image galleries, create new articles and edit existing ones.

Each class has its own ACL, defining which groups of users and individual users may, in the absence of other rules (see below) view and create new objects of that class and modify existing ones.
Each item also has an ACL, which determines which users and groups can view and edit its content via the Universal Item Editor or code contained in the controller.
If an item ACL has been left empty, the item will inherit the ACL class to which it belongs. Otherwise, the item ACL will prevail on its class ACL.
If both the item ACL and the class ACL are empty, the item will be publicly-editable (this can be a very useful feature in the implementation of a Wiki).
There are circumstances in which it may be desirable that the ACL is not temporarily taken into account. For instance, we could have a form to request registration for a new user, which creates a request for registration which will then be moderated by administrators.
In this case, ACL checks can be temporarily disabled for the currently running code, limited to the next WODBMS read or write call. This can be done by calling the function wos_ignore_acl().
It is the controller responsibility to ensure that user has rights to write on the WODBMS, in this case.
The ACL audit will be automatically restored after executing the WODBMS call, for security reasons.

How to modify and add classes in WODBMS

In the current Wedgefish version, the procedure for creating new classes and modify existing ones consists of these three steps:

• export the class to an XML file
• edit the definition of the class, or copy and paste an existing definition and edit it if you want to add a new class
• reimport the XML file in the system, taking care to specify that you want to override the classes with the same name, to avoid duplicates

Items already belonging to the edited class will be preserved.

In a future version of the platform, a web interface allowing to create new classes and modify existing ones will be included, allowing to start from definitions contained in models of modules to create new classes customized according to the website needs.