Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

We can encounter failures while importing content/data in Asta7 for several reasons. So far our approach for handling failures has been to throw an exception and abort the import. But this approach is not user-friendly as most of the failures are recoverable.

We want a tool to handle imports better to ease the mobility of archives between different Asta7 installations and within the same Asta7. The tool should be based on current functionality in Asta5 and adapted to the challenges we have in Asta7.

This tool will be used only for the Single Archive and Excel import from Asta7

Failures and Possible Solutions

Normal Entities

Failure

Solutions

Challenges

AMID conflict

  • Regenarate

  • Replace all objectReference

PK conflict

  • Regenaret if UUID

  • Input from the user

  • Replace all FK

  • How to handle composite PK?

Unique conflict

  • Regenarate if UUID

  • Input from the user

  • Set null if nullable

FK conflict

  • Set null if nullable

NULL conflict

  • Regenarate if UUID

  • Input from the user

Wrong type

  • Regenarate if UUID

  • Input from the user

  • Set null if nullable

Wrong length

  • Input from the user

  • Remove extra

  • Set null if nullable

FVP Unique conflict

  • Regenarate

  • Input from the user

System Entities

As we are only exporting the participant module and tag module for now we can ignore the other system templates for now. We need to consider the AKTOR and TAG entities for this section and ignore AMID/PK conflicts for all sub-entities. For the AKTOR and TAG entities, we should add some additional options for handling AMID/PK/Unique/FVP Unique conflicts.

Failure

Solutions

Challenges

AMID/PK/Unique/FVP Unique conflict

  • Ignore

  • Replace with the conflicted row

  • If ignored then need to ignore the whole subtree for this row as well

  • If replaced need to replace all objectReference and FK as well

  • Should we consider the possible new sub-entity objects?

  • Should we consider the possible changes for this subtree?

Implementation

  • No labels