Development:XMLDB roadmap: Difference between revisions
No edit summary |
mNo edit summary |
||
| Line 4: | Line 4: | ||
# <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]]: 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="red"> - Work in progress</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]]: 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="red"> - Nearly ended</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]]: 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="red"> - Work in progress</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]]: 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="red"> - Work in progress</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 Documenting everything|Documenting everything]]: 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 Documenting everything|Documenting everything]]: 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> | ||
Revision as of 19:21, 24 August 2006
XML database schema > 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).
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...).
Modifying DML functions - Work in progress: 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!
Defining one XML structure and handling it - Nearly ended: 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.
Creating new DDL functions - Work in progress: 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.
Modifying the installation/upgrade process - Work in progress: 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.
Documenting everything: 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.
