XMLDB introduction

XMLDB Documentation > Introduction

---

One of the main upcoming features in Moodle 1.7 was its ability to work with some more RDBMS (MSSQL and Oracle) while maintaining everything working properly with both MySQL and PostgreSQL. As Moodle core uses ADOdb internally, this possibility has been present since the beginning and, with the current maturity of the project (5 year old baby!), this can be a good moment to sort all this out.

Initially, all our tests and preliminary work was to inspect how ADOdb was doing its work, and how we could mix together all those 4 RDBMS, whose SQL dialects, although pretty similar, have some differences and idiosyncrasies that force us to do some important changes to our current database code (formerly datalib.php) and how it's used by the rest of Moodle.

All the changes to be performed, which primary objective is to enable Moodle to work with more RDBMS, must be fulfilled by following these non-functional requirements:

• Provide one layer (new) for DB creation/upgrade (DDL): With this, developers will create their structures in one neutral form, independent of the exact implementation to be used by each RDBMS.

• Provide one layer (existing) for DB handling (DML): With this, developers will request/store information also in one neutral form, independent of the RDBMS being used.

• Easy migration path from previous versions: The current installation/upgrade system will work until, at least, Moodle 2.0, allowing 3rd party developers to migrate to the new system.

• Simple, usable and effective: Until now, the way to upgrade Moodle has been really cool and it has worked pretty fine since the beginning. However, it has forced developers to maintain at least two installation and two upgrade scripts for each module/plugin. The new alternative will have only one file to install and one file to upgrade (per module/plugin too), reducing the possibility of mistakes drastically.

• Conditional code usage must be minimised: Database libraries must accept 99% of potential SQL sentences, building/transforming them as necessary to work properly under any RDBMS. The number of places using custom (per DB) code should be minimum.

• Well documented: All the functions defined, both at DML and DDL level must be well documented, helping the developer to find and use the correct one in each situation.

The Stack

The next stack shows how Moodle 1.7 code will interact with the underlying RDBMS. It will help us understand a bit more what we are trying to do and will explain some of the points related in the Roadmap (below in this page).

Moodle code will use two languages to perform its DB actions:

• XMLDB neutral description files: To create, modify and delete database objects (DDL: create/alter/drop tables, fields, indexes, constraints...). It consists of a collection of validated, standard, XML files. They will be used to define all the DB objects. New for 1.7.
• Moodle SQL neutral statements: To add, modify, delete and select database information (DML: insert/update/delete/select records). To modify for 1.7.

Please note the neutral keyword used in the expressions above. It means that both languages will be 100% the same, independent of the underlying RDBMS being used. And this must be particularly true for the XMLDB part.

Obviously it's possible that in the SQL part we find some specialised queries (using complex joins, regular expressions...) that will force us to do some Exceptions. Well, they can exist (in fact, they exist), but we always must try to provide an alternate path to minimise them using neutral statements and standard libraries.

Each one of the languages above will use its own library to do the work:

• Moodle DDL Library (ddllib.php): Where all the functions needed to handle DB objects will exist. This library is new for 1.7 and will provide developers with a high level of abstraction. As input it will accept some well defined objects and actions and it will execute the proper commands for the RDBMS being used.
• Moodle DML Library (dmllib.php): Where all the functions needed to handle DB contents will exist. This library is new for 1.7, although its contents are, basically, functions currently present in datalib.php (moved from there). All those DML functions will offer cross-db support for insert/update/delete/select statements using a common behaviour.

Also note that datalib.php is still present in the schema above. It will contain all the functions that haven't been moved to the new ddllib.php and dmllib.php libraries. Only some common functions will remain there, and these will disappear (it's considered a legacy library) in upcoming Moodle releases (after 1.7) by moving all those functions to their proper library (course/lib.php, user/lib.php....).

Both of these libraries (plus the small Exceptions bar) will perform all their actions using the ADOdb Database Abstraction Library for PHP that will receive all the requests from them, communicate with the DB (MySQL, PostgreSQL, Oracle or SQL*Server), retrieve results and forward them back to originator library.

The process

This section points to the main areas of information about the process of design and implementation of the new XMLDB layer:

• Roadmap: Where the whole process is defined. It has been split into small chunks to be performed and tested easily. Also, such documents should be used to track what's done and what's pending, while using easy nomenclature.

• Problems: A comprehensive list of issues that need to be determined/solved prior to incorporating them into the roadmap.

The documentation

This section points to the main documentation index about the implemented XMLDB:

• Documentation: Where you'll find quick links to different parts of the XMLDB documentation.

See also

XMLDB related

• XMLDB preliminary links - A collection of links about general info, searched and analysed at the initial stages of the project
• XMLDB preliminary notes - A collection of notes collected in the early stages of this project, pointing both to some changes required and some problems to solve.

Database related

• DDL functions - Documentation for all the Data Definition Language (DDL) functions available inside Moodle.
• DML functions - Documentation for all the Data Manipulation Language (DML) functions available inside Moodle.