Semplice rimozione dei documenti "tombali

Per rimuovere manualmente le pietre tombali, eseguire le seguenti operazioni:

1. Creare un database per contenere i documenti richiesti.

Il nuovo database è destinato a contenere tutti i documenti, tranne quelli relativi alle lapidi.

1. Impostare una replica filtrata per replicare i documenti dal database originale al nuovo database.

Configurare il filtro in modo che i documenti con l'attributo "_deleted" non vengano replicati.

1. Al termine della replica, cambiare la logica dell'applicazione per utilizzare il nuovo database.

2. Verificare che le applicazioni funzionino correttamente con il nuovo database.

Quando si è certi che tutto funziona correttamente, si può eliminare il vecchio database.

In generale, cercate di progettare e implementare le vostre applicazioni in modo da eseguire la quantità minima di cancellazioni necessaria.

Vedere un esempio di filtro per escludere i documenti eliminati durante una replica:

{
	"_id": "_design/filters",
	"filters": {
		"deleted_filter": "function(doc, req) { return !doc._deleted; };"
	}
}

Rimozione avanzata di documenti tombali

La semplice tecnica di rimozione funziona bene, se i documenti non vengono aggiornati nel database di origine durante la replica.

Se vengono effettuati aggiornamenti durante la replica, è possibile che un documento completo venga replicato normalmente nel database di destinazione, e venga eliminato anche dal database di origine, lasciando una pietra tombale. Il problema è che la pietra tombale non viene replicata nel database di destinazione perché la pietra tombale è esclusa dal filtro. Pertanto, il documento eliminato dal database di origine non viene eliminato dal database di destinazione, causando un'incoerenza.

Una soluzione è quella di effettuare una rimozione più avanzata delle pietre tombali utilizzando una funzione validate_doc_update.

Una funzione di validate_doc_update è memorizzata in un documento di progettazione. La funzione viene eseguita ogni volta che un documento viene aggiornato nel database. La funzione può essere utilizzata per prevenire aggiornamenti di documenti non validi o non autorizzati.

La funzione funziona utilizzando i seguenti parametri:

• La nuova versione del documento.
• La versione corrente del documento nel database.
• Un contesto utente, che fornisce dettagli sull'utente che ha fornito il documento aggiornato.

La funzione esamina la richiesta per determinare se l'aggiornamento è autorizzato a procedere. Se l'aggiornamento è accettabile, la funzione ritorna. Se l'aggiornamento non è accettabile, viene restituito un oggetto di errore appropriato. In particolare, se l'utente non è autorizzato a effettuare l'aggiornamento, viene restituito un oggetto unauthorized error, insieme a un messaggio di errore esplicativo. Allo stesso modo, l'aggiornamento richiesto potrebbe non essere consentito per qualche motivo, ad esempio quando alcuni campi obbligatori sono assenti dal nuovo documento. In questo caso, viene restituito un oggetto di errore forbidden, con un messaggio di errore esplicativo.

Per la rimozione della lapide, una funzione validate_doc_update adatta funzionerebbe come segue:

1. Se l'aggiornamento consiste nell'applicare una modifica a un documento esistente (oldDoc) all'interno del database di destinazione, la funzione consente la modifica restituendo il risultato.

Il motivo è che l'aggiornamento riguardava un documento copiato nel database di destinazione durante la replica, ma poi modificato nel database di origine durante la replica. È possibile che la modifica sia stata un DELETE, con il risultato di un record tombale nel database di destinazione. Il record della lapide viene rimosso da un successivo processo di replica in un momento futuro. 2. Il database di destinazione non ha una copia del documento corrente e il documento da aggiornare ha la proprietà _deleted (che indica che si tratta di una lapide). Pertanto, il documento aggiornato deve essere una pietra tombale ed è stato incontrato in precedenza, quindi l'aggiornamento del database di destinazione deve essere rifiutato.

Vedere un esempio JavaScript validate_doc_update per rifiutare i documenti eliminati non ancora presenti nel database di destinazione:

function(newDoc, oldDoc, userCtx) {
	// any update to an existing doc is OK
	if(oldDoc) {
		return;
	}

	// reject tombstones for docs we don’t know about
	if(newDoc["_deleted"]) {
		throw({forbidden : "Deleted document rejected"});
	}

	return; // Not strictly necessary, but clearer.
}

Per utilizzare una funzione validate_doc_update per rimuovere i documenti tombali:

1. Interrompere la replica dal database di origine a quello di destinazione.
2. Se necessario, eliminare il database di destinazione e creare un nuovo database di destinazione.
3. Aggiungere una funzione validate_doc_update adeguata, simile all'esempio fornito.
4. Aggiungetelo a un documento di progettazione nel database di destinazione.
5. Riavviare la replica tra il database di origine e quello di destinazione (nuovo).
6. Al termine della replica, cambiare la logica dell'applicazione per utilizzare il nuovo database.
7. Verificare che le applicazioni funzionino correttamente con il nuovo database.

Quando si è certi che tutto funziona correttamente, si può eliminare il vecchio database.

Ecco un'altra variante per l'utilizzo della funzione validate_doc_update per rimuovere, se possibile, i documenti tombali.

1. Aggiungere alcuni metadati ai documenti tombali, ad esempio per registrare la data di cancellazione.
2. Utilizzare la funzione per ispezionare i metadati e consentire il passaggio dei documenti di eliminazione se devono essere applicati al database di destinazione.

Questo controllo aiuta a garantire la corretta replica della cancellazione.

Implicazioni prestazionali della rimozione delle lapidi

Le pietre tombali sono utilizzate per eliminare in modo più coerente i documenti dai database. Questo scopo è particolarmente importante per i dispositivi mobili: senza documenti tombali, un'eliminazione potrebbe non essere replicata correttamente su un dispositivo mobile, con il risultato che i documenti potrebbero non essere mai eliminati dal dispositivo.

Se si ricrea un database, ad esempio, una nuova destinazione per una replica. I client che utilizzano il database di destinazione come server devono eseguire nuovamente tutte le modifiche, perché i numeri di sequenza del database potrebbero essere diversi.

Se si utilizza una funzione di validate_doc_update, evitare di replicarla ai clienti. Questa regola serve a prevenire la possibilità di effetti collaterali indesiderati derivanti dalla presenza della funzione sul client.

IBM Cloudant sincronizzazione le biblioteche non replicano i documenti di progettazione, quindi la replica delle funzioni di validate_doc_update non è normalmente un problema per IBM Cloudant. Tuttavia, altri clienti potrebbero replicare i documenti di progettazione o le funzioni di validate_doc_update, con potenziali effetti collaterali indesiderati.