XML.Import's default handling of data is "UPSERT", a mix of INSERT and UPDATE:
What?
|
Definition
|
Default handling
|
New record
|
The record is in the XML document.
A record with the same primary key does not exist in the database.
|
The record is INSERTed.
|
Changed record
|
The record is in the XML document.
A record with the same primary key also exists in the database.
|
The record is UPDATEd.
|
Other record
|
The record is not in the XML document.
It only exists in the database.
|
The record is not affected.
|
Default handling is overridden if the XML record has a DML instruction tag:
Example
Given this sample database:
EMPLOYEE: ID = 101, NAME = CELINE
ID = 102, NAME = ANJA
EMPLOYEE_LANGUAGE_SKILL: EMP_ID = 101, LANG = NL
EMP_ID = 101, LANG = SP
EMP_ID = 102, LANG = NL
EMP_ID = 102, LANG = SP
|
and this import document:
<?usoft-xml version="1.0" action="multi-tables-import" use-io-formats="no" verify-original-values="no" return-corrected-records ="yes"?>
<MultiImport>
<Employees>
<EMPLOYEE ID="101" NAME="SELINA"/>
<EMPLOYEE ID="103" NAME="LUCA"/>
</Employees>
<Employee_Language_Skills>
<EMPLOYEE_LANGUAGE_SKILL EMP_ID="101" LANG="NL" />
<EMPLOYEE_LANGUAGE_SKILL EMP_ID="103" LANG="NL" />
<EMPLOYEE_LANGUAGE_SKILL EMP_ID="103" LANG="SP" />
</Employee_Language_Skills>
</MultiImport>
|
The result of the import in the database will be:
EMPLOYEE: ID = 101, NAME = SELINA <= The NAME is updated
ID = 102, NAME = ANJA
ID = 103, NAME = LUCA <= A new record is inserted
EMPLOYEE_LANGUAGE_SKILL: EMP_ID = 101, LANG = NL <= The record is not affected
EMP_ID = 101, LANG = SP
EMP_ID = 102, LANG = NL
EMP_ID = 102, LANG = SP
EMP_ID = 103, LANG = NL <= A new record is inserted
EMP_ID = 103, LANG = SP <= A new record is inserted
|
|
When XML.Import processes an import document, the Rules Engine is active. It performs all the actions, corrections and checks defined for it.
|
When XML.Import is invoked by an INVOKE statement, the import is not automatically committed. It is the programmer or user who decides when to commit. It is therefore possible to:
•Execute an XML import, consider its result, and then commit the operation or roll it back as a separate action. •Execute an XML import in the middle of a transaction. •Have a transaction that consists of more than one XML import. |
As of USoft 9.1, when you use XML.Import to import a multi-table XML document, referential relationship checks are deferred until commit. This allows you to import parent-child record constellations without worrying about the order in which the records appear in the XML.
|
Obsolete children are child records that no longer exist in the import XML. You can get XML.Import to drop obsolete children by setting Type Of Relationship = Composition for the relationship.
If you are importing a document with DML instruction tags, you must block the "drop obsolete children" behaviour by specifying relationship-behaviour="as-reference" in the usoft-xml processing instruction (PI). Otherwise, an error is raised. With DML instruction tags, you can use the <Delete/> tag to manually determine exactly which records are to be dropped.
In the outcome of each data comparison (as produced in a file with name "... .diff. ..."), USoft Delivery Manager automatically adds relationship-behaviour="as-reference" to the usoft-xml processing instruction. This applies to metadata and application data alike. In summary, importing a Delivery Manager "... .diff. ..." file never causes obsolete children to be dropped automatically.
|
In your import document you are allowed to use DML instruction tags for some, but not all, records to be imported. This is referred to as "mixed-format XML".
Mixed-format XML is imported on a record-by-record basis:
•If there is a DML instruction tag, this tag dictates what XML.Import must do with the record. •If there is no DML instruction tag, the default "UPSERT" behavior applies. |
See also
XML.Import
XML.Import: Known problems and workarounds
|
