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: Difference between revisions

From MoodleDocs
mNo edit summary
 
mNo edit summary
Line 1: Line 1:
[[XML database schema]] > [[XMLDB Roadmap|Roadmap]] > Splitting datalib.php
[[XML database schema]] > [[XMLDB Roadmap|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. With the time we could reduce datalib by moving their functions to other libraries (course/lib.php, user/lib.php). Obviously, while we'll including all the 90 functions for each request, memory/process requirements will continue high. And some functions will be out of their ''natural'' place (i.e. a bit more disordered). This solution should be 100% compatible with 3rd part modules because everything will continue being available automatically.
* 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 related with this point should be performed in one branch, call it MOODLE_17_REORGANIZATION. ;-)


==See also==
==See also==

Revision as of 18:27, 18 June 2006

XML database schema > 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. With the time we could reduce datalib by moving their functions to other libraries (course/lib.php, user/lib.php). Obviously, while we'll including all the 90 functions for each request, memory/process requirements will continue high. And some functions will be out of their natural place (i.e. a bit more disordered). This solution should be 100% compatible with 3rd part modules because everything will continue being available automatically.
  • 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 related with this point should be performed in one branch, call it MOODLE_17_REORGANIZATION. ;-)

See also