|
An obsolete child is a child record that is considered to be no longer relevant if new information about the parent and its children is imported.
You can instruct XML.Import to delete obsolete children when importing new parent-child information. This applies when you pass parent and child records in a USoft multi-table XML document to XML.Import.
Whether or not XML.Import deletes obsolete children depends on the Type of Relationship of the Relationship between parent and child.
If Type Of Relationship = Reference (the default), child records in the database that do not exist in the XML are NOT deleted.
If Type Of Relationship = Composition, child records in the database that do not exist in the XML ARE deleted.
A child record is considered "not to exist" (see Example 2) in the XML only if both of the following apply:
•The wrapper element with the child table's Object Name Plural is in the XML. •Inside this wrapper, no record exists with the primary key value(s) of the child record. There is a processing instruction called "relationship-behaviour" with which you can direct the engine to treat "Composition" relationships as if they were "Reference" relationships. See Example 4 or go to " usoft-xml processing instruction " for details.
The following examples are imported into this sample database, where the relationship between EMPLOYEE and EMPLOYEE_LANGUAGE_SKILL has Type Of Relationship = Composition:
Table: EMPLOYEE
ID
|
NAME
|
101
|
CELINE
|
102
|
ANJA
|
Table: EMPLOYEE_LANGUAGE_SKILL
EMP_ID
|
LANG
|
101
|
NL
|
101
|
SP
|
102
|
NL
|
102
|
SP
|
This example shows how obsolete children are handled when child records are present in the XML 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 importing this document will be:
Table: EMPLOYEE
ID
|
NAME
|
Comments
|
101
|
SELINA
|
The NAME is updated.
|
102
|
ANJA
|
|
103
|
LUCA
|
A new record is inserted.
|
Table: EMPLOYEE_LANGUAGE_SKILL
EMP_ID
|
LANG
|
Comments
|
101
|
NL
|
|
|
|
Record 101, SP is deleted.
|
102
|
NL
|
|
102
|
SP
|
|
103
|
NL
|
A new record is inserted.
|
103
|
SP
|
A new record is inserted.
|
|
This example shows how an empty table wrapper in the XML document has the meaning "children do not exist". Obsolete children are deleted. Contrast with Example 3:
<?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/>
</MultiImport>
The result of importing this document will be:
Table: EMPLOYEE
ID
|
NAME
|
Comments
|
101
|
SELINA
|
The NAME is updated.
|
102
|
ANJA
|
|
103
|
LUCA
|
A new record is inserted.
|
Table: EMPLOYEE_LANGUAGE_SKILL
EMP_ID
|
LANG
|
Comments
|
|
|
Record 101, NL is deleted.
|
|
|
Record 101, SP is deleted.
|
|
|
Record 102, NL is deleted.
|
|
|
Record 102, SP is deleted.
|
|
This example how an XML document with NO reference to a table does not affect child records. Existing children are not considered obsolete, and consequently are not dropped. Contrast with Example 2:
<?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>
</MultiImport>
The result of importing this document will be:
Table: EMPLOYEE
ID
|
NAME
|
Comments
|
101
|
SELINA
|
The NAME is updated.
|
102
|
ANJA
|
|
103
|
LUCA
|
A new record is inserted.
|
Table: EMPLOYEE_LANGUAGE_SKILL
EMP_ID
|
LANG
|
Comments
|
101
|
NL
|
Record not in XML, but preserved.
|
101
|
SP
|
Record not in XML, but preserved.
|
102
|
NL
|
Record not in XML, but preserved.
|
102
|
SP
|
Record not in XML, but preserved.
|
|
This example shows how obsolete children in a composition relationship can be preserved by instruction XML.Import, in the relationship-behaviour processing instruction at the top, to treat the relationship as a reference relationship during the import. Contrast with Example 1.
<?usoft-xml version="1.0" action="multi-tables-import" relationship-behaviour="as-reference"
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 importing this document will be:
Table: EMPLOYEE
ID
|
NAME
|
Comments
|
101
|
SELINA
|
The NAME is updated
|
102
|
ANJA
|
|
103
|
LUCA
|
A new record is inserted.
|
Table: EMPLOYEE_LANGUAGE_SKILL
EMP_ID
|
LANG
|
Comments
|
101
|
NL
|
.
|
101
|
SP
|
Record not in XML, but preserved.
|
102
|
NL
|
|
102
|
SP
|
|
103
|
NL
|
|
103
|
SP
|
A new record is inserted.
|
|
See also
How import XML is processed
XML.Import
|
