Note:

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

XMLDB creating new DDL functions - pre 2.0: Difference between revisions

From MoodleDocs
Line 4: Line 4:
== Justification ==
== Justification ==


Before Moodle 1.6, all the DB install and upgrade was developed twice (once to handle MySQL installations and another to handle PostgreSQL installations). This approach, although working, has caused some headaches in the past, mainly because it was really difficult to keep both lines of development 100% on sync. Some developers do they work against one RDBMS and it was complex to develop to the other one (two test environments, skills on both databases, slower development cycle...). And all this was happening with ''only'' two supported RDBMS!
Once the [[XMLDB Defining one XML structure|XMLDB Structure]] has been well defined and we are able to abstract any DB model with it, it's time to build one group of functions that will create the needed DB objects based in the information supplied by such XML structure. All those functions will use the underlying XMLB objects (XMLDBTable, XMLDBField, XMLDBKey, XMLDBIndex) in order to keep the level of abstraction across them.


One of the main objectives of Moodle 1.7 is to extend the the number of supported RDBMS to other flavours (more exactly, to Oracle and MSSQL). And the old approach (one line of development for each DB) could become an absolute nightmare.  
The objectives to be supplied by these functions are:
 
* Be used by the '''installation''' process, replacing the old *.sql usage, to create all the needed DB objects.
* Be used by the ''''upgrade''' process, in the new upgrade.php script, to handle all the DB objects.
 
Although initially it wasn't completely decided if all those XMLDB objects were going to be used by the DDL functions, or we were going to create a bunch of new functions, completely independent from the XMLDB schema, finally we decided to use the previously created object, mainly because:
 
* If we have some objects representing tables, fields and so on, it hasn't too much sense to build new functions requiring the same type of objects as parameters and not to use them.
* Any change in the XMLDB objects will be immediately available to the DDL functions (one new column type...).
* Code inside the DDL functions will be pretty simple because all the SQL code generation will be the responsibility of the XMLDB classes themselves.
* By using the XMLDB objects, the XMLDB Editor (the tool to edit XMLDB structures easily) could be improved in order to generate automatically the needed PHP code to be used by the upgrade.php scripts. Just select one object (table/field/index/key), one action to perform (create/drop/rename/alter) and, wow!, you will obtain all the PHP code to be pasted in the upgrade script. (coming soon) ;-)
 
The only drawback we have found is that upgrade code will be a bit longer, because it will need to include all the XMLD objects creation and definition code. But, in the other hand, it will be an easy readable code.


== Implementation ==
== Implementation ==

Revision as of 17:45, 13 August 2006

XML database schema > Roadmap > XMLDB Creating new DDL functions

Justification

Once the XMLDB Structure has been well defined and we are able to abstract any DB model with it, it's time to build one group of functions that will create the needed DB objects based in the information supplied by such XML structure. All those functions will use the underlying XMLB objects (XMLDBTable, XMLDBField, XMLDBKey, XMLDBIndex) in order to keep the level of abstraction across them.

The objectives to be supplied by these functions are:

  • Be used by the installation process, replacing the old *.sql usage, to create all the needed DB objects.
  • Be used by the 'upgrade process, in the new upgrade.php script, to handle all the DB objects.

Although initially it wasn't completely decided if all those XMLDB objects were going to be used by the DDL functions, or we were going to create a bunch of new functions, completely independent from the XMLDB schema, finally we decided to use the previously created object, mainly because:

  • If we have some objects representing tables, fields and so on, it hasn't too much sense to build new functions requiring the same type of objects as parameters and not to use them.
  • Any change in the XMLDB objects will be immediately available to the DDL functions (one new column type...).
  • Code inside the DDL functions will be pretty simple because all the SQL code generation will be the responsibility of the XMLDB classes themselves.
  • By using the XMLDB objects, the XMLDB Editor (the tool to edit XMLDB structures easily) could be improved in order to generate automatically the needed PHP code to be used by the upgrade.php scripts. Just select one object (table/field/index/key), one action to perform (create/drop/rename/alter) and, wow!, you will obtain all the PHP code to be pasted in the upgrade script. (coming soon) ;-)

The only drawback we have found is that upgrade code will be a bit longer, because it will need to include all the XMLD objects creation and definition code. But, in the other hand, it will be an easy readable code.

Implementation

Basic Concepts

Handling XMLDB objects

Integration with the XMLDB Editor

See also

  • DDL functions: To get access to the updated documentation about the functions available to modify the DB objects.
  • XML structure: To know a bit more about the internal XML structure used to describe all the DB objects using one neutral language.
  • List of functions to create: The list of functions to be created from scratch. Used to follow the progress and its status.
Retrieved from "https://docs.moodle.org/dev/index.php?title=XMLDB_creating_new_DDL_functions_-_pre_2.0&oldid=5062"
Powered by MediaWiki