When using Nerada, it is recommended to manually align the search database and Nerada database to increase the query response consistency.
Using the afs:paf_id query parameter ensures a response alignment when querying the web services.
Even if the afs:paf_id query parameter is used to synchronize the search and Nerada databases, a desynchronization is still possible in case of PaF failure if the filter order is not optimal.
Example of a desynchronization in the nominal case
The following example shows a desynchronization for a sequence of two PaF runs:
- PaF #1: FULL: Upload document with URI urn:1.
- PaF #2: INCREMENTAL: Delete the document with URI urn:1.
If the CONTENT is online before being in the search database, the search database may still be at PaF #1, returning the document with urn:1 while this document does not exist anymore in the online CONTENT at PaF #2.
Example of a desynchronization in cases of failure
The following example shows all possible cases where a desynchronization may happen for a sequence of three PaF runs:
- PaF #1: FULL: Upload document with content A and URI urn:1.
- PaF #2: INCREMENTAL: Modify (or delete) the document with URI urn:1 so that its content is B.
- PaF #3: INCREMENTAL: No effect on the document with URI urn:1.
For instance, the search engine considers that the document with urn:1 contains A, and returns it to a query searching for "A".
However, when Nerada receives a query asking for a document with urn:1, it returns:
- The document B if the PaF #2 modified the document
- A 404 error if the PaF #2 deleted the document. This is the case even if the query parameter afs:paf_id was set to the most recent value, afs:paf_id=3.
The search provides the first PaF ID (1) and the last PaF ID (3).
One way to solve this problem is by running a FULL indexation.
To minimize the possibility of desynchronization, the following PaF configuration is recommended, in this exact order:
This filter order ensures that, in case of PaF failure, all services are correctly deployed.