Development:XMLDB roadmap: Difference between revisions
mNo edit summary |
mNo edit summary |
||
| (18 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
[[ | [[Development:XMLDB Documentation|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). | 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 | # <p>[[Development: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 [[Development: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 [[Development: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 | # <p>[[Development: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 | # <p>[[Development:XMLDB defining an 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 | # <p>[[Development: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]]: 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>[[Development: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 | #<p>[[Development: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]] | ||
Latest revision as of 18:04, 31 July 2008
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).
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 - 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!
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.
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.
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.
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.
