XDMP-DBDUPURI exceptions

Moderator: Reach-Native-gp

Post Reply
Posts: 16
Joined: Thu Oct 01, 2020 4:13 pm

XDMP-DBDUPURI exceptions

Post by rahulburman »

How to prevent XDMP-DBDUPURI exceptions? When do they occur?

Posts: 21
Joined: Thu Oct 01, 2020 4:10 pm

Re: XDMP-DBDUPURI exceptions

Post by amitgope »

An XDMP-DBDUPURI error will occur if the same URI occurs in multiple forests of the same database. Same URI can end up in a DB under the following circumstances:
1. By detaching a forest from its parent database (for administrative purposes - e.g., backup, restore) while allowing updates to continue on the database. If an update is committed to an Uri that exists on the detached forest, the database will create a new Uri on a different forest. When the forest is re-attached to the database, you will have duplicates of these Uris.

2. By detaching a forest from database-1 and then attaching it to database-2. Database-2 may already have some of the Uris that the new forest contains, including directory Uris such as "/".

3. By by doing a forest restore from forest-a to forest-b, where the database that contains forest-b already has some Uris that also exist on forest-a.

4. By using an xdmp:eval() to insert content with one or more forests set in the database option. We normally check whether a Uri exists in all forests before inserting, but xdmp:eval bypasses that safeguard.

To prevent case #1: Instead of detaching the forest to perform administrative operations, put the forests in read-only mode instead. You can do this by setting 'updates-allowed' to 'read-only' in the forest settings. This will let the database know that a given Uri exists, but will disallow updates on it, thus preventing any duplicates from beuing created.

Case #2 can be prevented by not using forest attach/detach for content migration between databases. There are other alternatives such as replication.

The best way to avoid case #3 is by using database, rather then forest restore. If you must use forest restore, make sure to use an Admin API script that double-checks that any given forest backup is being restored to the corresponding restore target. Be sure to test your script thoroughly before deploying to production.

Case$4: avoid using 'place keys' (specifying a forest in the database option) during document inserts. This will allow the database to decide where the document goes and thereby prevent duplicates. You can also use the API xdmp:document-assign() to figure out where xdmp:document-insert() would place that Uri, and then pass that value in the xdmp:eval(), e.g., in the if-eval function below, you can either use a hardcoded forest name

Post Reply