XMLDB defining an XML structure: Difference between revisions
mNo edit summary |
mNo edit summary |
||
Line 1: | Line 1: | ||
[[XML database schema]] > [[XMLDB Roadmap|Roadmap]] > Defining one XML structure | [[XML database schema]] > [[XMLDB Roadmap|Roadmap]] > Defining one XML structure | ||
---- | ---- | ||
== 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! | 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! | ||
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. | |||
Because of this we have planned to build one structure to define all the DB objects used by Moodle. This structure will provide the necessary level of abstraction to be shared by all the RDBMS systems, so the "multiple lines of development" explained in the previous paragraph will be out forever, giving us one robust and well defined way to handle DB objects independently of the exact RDBMS being used. | |||
== Implementation == | |||
Initially all our best wishes were to use the [http://phplens.com/lens/adodb/docs-datadict.htm#xmlschema AdoDB XML Schema]. As Moodle is using ADOdb libraries to communicate with databases it sounded like the natural approach to solve the problem. But, finally, two reasons prevented us to use it: | |||
# Although working, it seems to be one feature in progress, with important changes/evolutions arriving at the time of write this document. | |||
# Its lack of support for "prefixes" (one Moodle key feature, to allow multiple instances to run in the same server), would force us to create some awful tricks to generate the objects. | |||
So, finally, we decided to build our own XML files, with everything we need to define every object present in the DB and then, the task started without more comments. | |||
The | == The XML editor == | ||
XML | XML |
Revision as of 16:18, 9 August 2006
XML database schema > Roadmap > Defining one XML structure
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!
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.
Because of this we have planned to build one structure to define all the DB objects used by Moodle. This structure will provide the necessary level of abstraction to be shared by all the RDBMS systems, so the "multiple lines of development" explained in the previous paragraph will be out forever, giving us one robust and well defined way to handle DB objects independently of the exact RDBMS being used.
Implementation
Initially all our best wishes were to use the AdoDB XML Schema. As Moodle is using ADOdb libraries to communicate with databases it sounded like the natural approach to solve the problem. But, finally, two reasons prevented us to use it:
- Although working, it seems to be one feature in progress, with important changes/evolutions arriving at the time of write this document.
- Its lack of support for "prefixes" (one Moodle key feature, to allow multiple instances to run in the same server), would force us to create some awful tricks to generate the objects.
So, finally, we decided to build our own XML files, with everything we need to define every object present in the DB and then, the task started without more comments.
The XML editor
XML
Difficult to edit, so editor provided
- Install
- Use
- Conventions
- Structure (assignment)
- Example and DTD
- Future Improvements
See also
- List of files to create: The list of files to be created from scratch. Used to follow the progress.
- http://www.hitsw.com/xml_utilites: One online XML-DTD-Schema conversor.