Note:

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

XMLDB roadmap: Difference between revisions

From MoodleDocs
mNo edit summary
No edit summary
Line 3: Line 3:
Extending DB support to new RDBMS implies a lot of changes in current code, plus the creation of some new libraries/artifacts. In this chapter, the main points of the whole process are related and explained briefly. Please note that points are numbered and should be performed in that order (when parallel work is possible it's pointed).
Extending DB support to new RDBMS implies a lot of changes in current code, plus the creation of some new libraries/artifacts. In this chapter, the main points of the whole process are related and explained briefly. Please note that points are numbered and should be performed in that order (when parallel work is possible it's pointed).


# <p>[[XMLDB Splitting datalib.php|Splitting datalib.php]]<font color="green"> - Done!</font>: Currently such file includes SQL DDL (table_column()...), SQL DML (select, insert...) and some functions that aren't related directly with ADOdb (category_parent_visible, print_object()...). With more and more functions coming to support new RDBMS (DDL mainly), it could be a good idea to split the file into 3 parts, one to handle DDL (creation/alter/drop.. - could be called [[DDL functions|ddllib.php]], only used on install/upgrade/migration), other to handle DML (where all the current insert, select, update.. functions will go - called [[DML functions|dmllib.php]]) and other to store all those non-ADOdb related functions (or move them to their proper lib - course/lib.php, user/lib.php...).</p>
# <p>[[XMLDB splitting datalib.php|Splitting datalib.php]]<font color="green"> - Done!</font>: Currently such file includes SQL DDL (table_column()...), SQL DML (select, insert...) and some functions that aren't related directly with ADOdb (category_parent_visible, print_object()...). With more and more functions coming to support new RDBMS (DDL mainly), it could be a good idea to split the file into 3 parts, one to handle DDL (creation/alter/drop.. - could be called [[DDL functions|ddllib.php]], only used on install/upgrade/migration), other to handle DML (where all the current insert, select, update.. functions will go - called [[DML functions|dmllib.php]]) and other to store all those non-ADOdb related functions (or move them to their proper lib - course/lib.php, user/lib.php...).</p>
#  <p>[[XMLDB Modifying DML functions|Modifying DML functions]]<font color="green"> - Done!</font>: Some changes have to be performed to extend support for other RDBMS in all this functions, like changes to support LIMIT clauses (that are emulated both under Oracle and MSSQL), insert_record() changes, handling of CLOB/BLOB (large text/binary objects...) and so on. While all this changes are performed in datalib.php, code across Moodle must be modified to perform the correct function calls. This point must be performed '''after point 1 was finished'''. This is really a big point!</p>
#  <p>[[XMLDB modifying DML functions|Modifying DML functions]]<font color="green"> - Done!</font>: Some changes have to be performed to extend support for other RDBMS in all this functions, like changes to support LIMIT clauses (that are emulated both under Oracle and MSSQL), insert_record() changes, handling of CLOB/BLOB (large text/binary objects...) and so on. While all this changes are performed in datalib.php, code across Moodle must be modified to perform the correct function calls. This point must be performed '''after point 1 was finished'''. This is really a big point!</p>
# <p>[[XMLDB Defining one XML structure|Defining one XML structure and handling it]]<font color="green"> - Done!</font>: The new XML structure used to define any DB (used at installation) should be as complex as needed, defining all the info required to transform it into usable DDL statements against any RDBMS. Validation and some sort of edition/inverse engineering will be present. This point can be performed '''in parallel with 1 & 2'''.</p>
# <p>[[XMLDB defining one XML structure|Defining one XML structure and handling it]]<font color="green"> - Done!</font>: The new XML structure used to define any DB (used at installation) should be as complex as needed, defining all the info required to transform it into usable DDL statements against any RDBMS. Validation and some sort of edition/inverse engineering will be present. This point can be performed '''in parallel with 1 & 2'''.</p>
# <p>[[XMLDB Creating new DDL functions|Creating new DDL functions]]<font color="green"> - Done!</font>: In order to be able to install/upgrade any DB component of Moodle, we need to suppot a bunch of new functions to CREATE/DROP/ALTER table, indexes, constraints, sequences, fields. All this functions should be cross-compatible and generate the proper SQL for each RDBMS. They will reside in the new ddllib.php (point 1) and will be included only in the installation/upgrade processes. This point must be performed '''after point 3 was finished'''.</p>
# <p>[[XMLDB creating new DDL functions|Creating new DDL functions]]<font color="green"> - Done!</font>: In order to be able to install/upgrade any DB component of Moodle, we need to suppot a bunch of new functions to CREATE/DROP/ALTER table, indexes, constraints, sequences, fields. All this functions should be cross-compatible and generate the proper SQL for each RDBMS. They will reside in the new ddllib.php (point 1) and will be included only in the installation/upgrade processes. This point must be performed '''after point 3 was finished'''.</p>
# <p>[[XMLDB Modifying the installation/upgrade process|Modifying the installation/upgrade process]]<font color="green"> - Done!</font>: While compatibility with the old method will be present and any module/block/format/question... could use that approach, 1.7 should use (for the whole official distro) a new approach. This will be based in the version number (like the current one) and will execute any action defined in one new XML file (replacing current *.sql files) and one new upgrade.php file (replacing current *php files). Both MySQL and PostgreSQL installations will be able to run both upgrade systems (first, the old one, then the new one) but new RDBMS only will work with the new one. In any case, the old one will become deprecated and will disappear in 2.0. This point must be performed '''after point 4 was finished'''.</p>
# <p>[[XMLDB modifying the installation/upgrade process|Modifying the installation/upgrade process]]<font color="green"> - Done!</font>: While compatibility with the old method will be present and any module/block/format/question... could use that approach, 1.7 should use (for the whole official distro) a new approach. This will be based in the version number (like the current one) and will execute any action defined in one new XML file (replacing current *.sql files) and one new upgrade.php file (replacing current *php files). Both MySQL and PostgreSQL installations will be able to run both upgrade systems (first, the old one, then the new one) but new RDBMS only will work with the new one. In any case, the old one will become deprecated and will disappear in 2.0. This point must be performed '''after point 4 was finished'''.</p>
#<p>[[XMLDB Documentation|Documenting everything]]<font color="red"> - Work in progress</font>: All the libraries above plus the new install/upgrade system must be completely documented to allow developers one easy migration from the old approach. Things like field types, forbidden words an so on must be well defined in order to allow the quick adoption and better usage of all the system. This point can be performed '''in parallel with points 1-5'''.</p>
#<p>[[XMLDB Documentation|Documenting everything]]<font color="red"> - Work in progress</font>: All the libraries above plus the new install/upgrade system must be completely documented to allow developers one easy migration from the old approach. Things like field types, forbidden words an so on must be well defined in order to allow the quick adoption and better usage of all the system. This point can be performed '''in parallel with points 1-5'''.</p>




[[Category:XMLDB]]
[[Category:XMLDB]]

Revision as of 17:02, 28 February 2007

XMLDB Documentation > XMLDB Roadmap


Extending DB support to new RDBMS implies a lot of changes in current code, plus the creation of some new libraries/artifacts. In this chapter, the main points of the whole process are related and explained briefly. Please note that points are numbered and should be performed in that order (when parallel work is possible it's pointed).

  1. Splitting datalib.php - Done!: Currently such file includes SQL DDL (table_column()...), SQL DML (select, insert...) and some functions that aren't related directly with ADOdb (category_parent_visible, print_object()...). With more and more functions coming to support new RDBMS (DDL mainly), it could be a good idea to split the file into 3 parts, one to handle DDL (creation/alter/drop.. - could be called ddllib.php, only used on install/upgrade/migration), other to handle DML (where all the current insert, select, update.. functions will go - called dmllib.php) and other to store all those non-ADOdb related functions (or move them to their proper lib - course/lib.php, user/lib.php...).

  2. Modifying DML functions - Done!: Some changes have to be performed to extend support for other RDBMS in all this functions, like changes to support LIMIT clauses (that are emulated both under Oracle and MSSQL), insert_record() changes, handling of CLOB/BLOB (large text/binary objects...) and so on. While all this changes are performed in datalib.php, code across Moodle must be modified to perform the correct function calls. This point must be performed after point 1 was finished. This is really a big point!

  3. Defining one XML structure and handling it - Done!: The new XML structure used to define any DB (used at installation) should be as complex as needed, defining all the info required to transform it into usable DDL statements against any RDBMS. Validation and some sort of edition/inverse engineering will be present. This point can be performed in parallel with 1 & 2.

  4. Creating new DDL functions - Done!: In order to be able to install/upgrade any DB component of Moodle, we need to suppot a bunch of new functions to CREATE/DROP/ALTER table, indexes, constraints, sequences, fields. All this functions should be cross-compatible and generate the proper SQL for each RDBMS. They will reside in the new ddllib.php (point 1) and will be included only in the installation/upgrade processes. This point must be performed after point 3 was finished.

  5. Modifying the installation/upgrade process - Done!: While compatibility with the old method will be present and any module/block/format/question... could use that approach, 1.7 should use (for the whole official distro) a new approach. This will be based in the version number (like the current one) and will execute any action defined in one new XML file (replacing current *.sql files) and one new upgrade.php file (replacing current *php files). Both MySQL and PostgreSQL installations will be able to run both upgrade systems (first, the old one, then the new one) but new RDBMS only will work with the new one. In any case, the old one will become deprecated and will disappear in 2.0. This point must be performed after point 4 was finished.

  6. Documenting everything - Work in progress: All the libraries above plus the new install/upgrade system must be completely documented to allow developers one easy migration from the old approach. Things like field types, forbidden words an so on must be well defined in order to allow the quick adoption and better usage of all the system. This point can be performed in parallel with points 1-5.