XML Export/Import Wrappers

The C#, Java, and Python wrappers provide a simplified, file-oriented interface for XML database export and import. These wrapper methods act as a convenience layer over the core C XML API, specifically:

• mco_db_xml_export()
• mco_db_xml_import()
• mco_xml_get_policy()
• mco_xml_set_policy()

The wrapper behavior is intentionally aligned with the XML export/import behavior exposed by SQL and xSQL (via export_xml(), import_xml(), exportxml, and importxml). This interface is particularly useful when a database must be migrated between configurations that are incompatible with binary snapshots—for example, after changing the in-memory page size, disk page size, transaction manager, or other parameters that affect binary database images.

Conceptual Model

Unlike binary snapshot save/load operations, XML export/import serializes logical database objects. The target database must already be opened with a compatible schema/dictionary, and the XML import procedure creates objects within that opened database.

The wrapper methods provide a streamlined, file-oriented workflow:

• Export: Opens the requested XML file for writing, starts a READ_ONLY transaction, applies the default XML policy, and calls the core XML export function.
• Import: Opens the requested XML file for reading, starts a READ_WRITE transaction, applies the XML policy, and calls the core XML import function.

During import, the wrappers can optionally accept an import transaction size parameter. A value of 0 indicates that the entire import should be processed within a single transaction.

Note: The simplified wrapper interface does not expose custom stream callbacks directly. Applications that require custom XML streams, compression pipelines, or non-file storage destinations should use the lower-level C XML API or another product interface that exposes stream callbacks.

XML Policy Configuration

To support whole-database migration, the wrappers automatically configure the XML policy before invoking the core API. Specifically, the following policy values are set:

    policy.ignore_autoid = MCO_NO;
    policy.ignore_autooid = MCO_NO;
            

For import operations, the wrappers also set the transaction size:

    policy.transaction_size = transactionSize;
            

By setting ignore_autoid and ignore_autooid to MCO_NO, the autoid and autooid values from the XML stream are preserved rather than being regenerated by the database runtime. This is the recommended behavior for migrating a database into a freshly opened target, especially when application relationships depend on these specific identifiers.

If an application intentionally imports XML into a non-empty database, the standard XML import rules apply: imported objects are added to the target database, and duplicate unique keys or invalid object references will cause the import transaction to fail.

More detailed information about the XML export/import functionality can be found at the following links::

• XML Export/Import in Csharp
• XML Export/Import in Java
• XML Export/Import in Python

Notes and Recommendations

• XML export/import is a logical data migration mechanism, not a byte-for-byte database image mechanism.
• For migration, open the target database with the desired new runtime/database parameters and a compatible schema, then import the XML into that target database.
• The XML file can be larger than a binary database image because it contains textual tags and encoded values. If size is a concern, use compression around the file or use a lower-level streaming API that can integrate compression.
• Compressed BLOB values stored in the database are exported as stored database values; the XML export/import procedure does not intentionally decompress and recompress them.
• XML import adds data to the currently opened target database. For whole-database migration, import into a fresh empty database.
• If imported classes use autoid or autooid, the wrappers preserve values from XML. This is important when relationships or application logic depend on those identifiers.
• If transactionSize is 0, import is performed as one import transaction. A positive value can be used to limit import transaction size for large databases.