The replication output file is in the XML format. XML is flexible, standardized, and supports replication needs easily. If the structure of the Midgard database is changed, no changes to Repligard code are needed as it can be made to support the new objects by simple changes to the XML schema file.
The XML schema file is very simple. It contains several XML elements in a two level structure. First element is type. Type specifies object name. Inside type we have a second structure that describes fields for that object. Example:
Besides field, we also have an element called link, that links objects to each other. After parsing the XML schema file, Repligard creates a graph noting relations between different objects. If the person has a link for a topic, then when exporting the person, the topic should also be exported and vise versa.
Sometimes such bidirectional relation isn't needed, as in case of page and host relation. When page is exported there is no need to export host because page might be used in several hosts simultaneusly. If exporting of bidirectional dependencies is not desired, there is additional attribute reverse='no' for the link element.
An object may contain either fields or links, but usually contains a mixture of both.
Repligard doesn't care which database software is being used, as it uses Midgard-lib for database interaction. This was done to minimize impact of porting Midgard to other databases than MySQL.
The schema XML files can be modified for application needs. As an example, Midgard articles contain three number fields can be used for linking to other objects. To make these replication safe, change your schema file to make Midgard aware of the linkage.
Example: Originally Midgard has:
<type name="article"> ... <field name="extra1" type="text" /> ... </type> |
Change this to:
<type name="article"> ... <link name="extra1" link="person" /> ... </type> |
In this case the schema XML file needs to be distributed with the application.