Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

XMLDB splitting datalib.php

From MoodleDocs

XMLDB Documentation > Roadmap > Splitting datalib.php


The main objective for this point is to isolate Moodle DML functions to one library and DDL functions to another one. This point must be performed before any other point in order to have everything in place before starting to modify everything else.

Currently there are 94 functions defined in lib/datalib.php where most of them (50) are not directly related with DML or DDL statements at all but with some commonly used DB transactions (let's call them functional functions. The rest (44) are core functions (from the perspective of being general, used by any script, to access to any table info), used to access to DB (with 42 functions used to handle data - DML - and 2 functions used to handle objects - DDL).

With the adoption of one XMLDB schema, the number of DDL functions will grown beyond its current limits, to have a collection of functions able to perform any operation with DB objects in a common way. Functions to create/alter/drop tables, fields, indexes and constraints will be necessary.

All these DDL functions will be used exclusively at install/upgrade time, so it would be a good idea to put all them together in a new library (ddllib.php), included only when necessary.

Also, it would be great to separate all those 44 core functions from the other 50 functional functions, in order to have everything isolated in its own library.

It seems that there are two approaches for all these changes:

  • Create two new libraries (ddllib.php and dmllib.php) and leave datalib.php for functional functions. It's simple, clear, with both datalib and dmllib being included always and ddllib only when necessary. Along the time (after 1.7 release) we could reduce datalib.php by moving their remaining functions to other libraries (course/lib.php, user/lib.php...). Until then we'll be including all the 90 functions for each request, so memory/process requirements will continue high (not higher than 1.6). And some functions will be out of their natural place (i.e. a bit more disordered). This solution is 100% compatible with 3rd part modules because everything will continue being automatically available.
  • Create one new library (dddlib.php), leaving datalib.php for core functions and move functional functions to other libraries. This alternative is more radical because a lot of scripts must be changed in order to allow everything to continue working, but every function will finish in its correct place. Memory/process requirements will be lower because functional functions will be included only if necessary. This solution won't be compatible with 3rd part modules because some functions won't be automatically available.

After analysing both alternatives, I think that the 1st one is better, less radical and will provide us and 3rd part developers with time to smoothly upgrade everything later (Moodle 2.0 could be a good moment to have all those functional functions moved to their final place.

All the work should be performed in one branch, call it MOODLE_17_DB_LIBRARIES and merge it back to HEAD before starting with Point 2: Modifying DML functions

Details

  1. Create the MOODLE_17_DB_LIBRARIES branch.
  2. Create the new dmllib.php library where all the DML functions will exist, moving them from datalib.php.
  3. Always require_once() that function in setup.php.
  4. Create the new ddllib.php library where all the DDL functions will exist, moving them from datalib.php.
  5. require_once() the new ddllib.php library in the installation/upgrade code (admin/index.php).
  6. Test installation/upgrade process.
  7. Merge the MOODLE_17_DB_LIBRARIES back to HEAD.

Timeframe

  • 2 days to do it, documenting every DDL and DML function.
  • 1 day to test it, checking that both normal operations and install-upgrade continue working properly.

Total: 3 days