Cosa posso fare per prevenire conflitti di scrittura / scrittura su un sito Web in stile wiki?

Question

Su un sito Web in stile wiki, cosa posso fare per prevenire o mitigare conflitti di scrittura-scrittura pur consentendo al sito di funzionare rapidamente e mantenendo il sito facile da usare?

Il problema che prevedo è questo:

1. L'utente A inizia a modificare un file
2. L'utente B inizia a modificare il file
3. L'utente A termina la modifica del file
4. L'utente B termina la modifica del file, sovrascrivendo accidentalmente tutte le modifiche dell'utente A

Ecco alcuni approcci che ho escogitato:

• Avere una sorta di sistema di check-out / check-in / lock (anche se non so come impedire alle persone di tenere un file estratto "troppo a lungo", e non voglio che gli utenti siano frustrati non essendo autorizzato a effettuare una modifica)
• Avere una sorta di diff che mostra altre modifiche apportate quando un utente commette le proprie modifiche e consente una sorta di unione (ma sono preoccupato che questo sarà difficile da creare e renderebbe il sito "troppo difficile" da utilizzare)
• Notifica agli utenti le modifiche simultanee mentre stanno apportando le loro modifiche (una sorta di AJAX?)

Altri modi per farlo? Qualche esempio di siti che lo implementano bene?

Answer 1

Ricorda il numero di versione (o ID) dell'ultima modifica. Quindi leggi la voce prima di scriverla e confronta se questa versione è sempre la stessa.

In caso di conflitto, informare l'utente che stava tentando di scrivere la voce che è stata modificata nel frattempo. Sostienilo con un diff.

La maggior parte dei wiki lo fanno in questo modo. MediaWiki , Usemod , etc .

Answer 2

Fusione in tre direzioni: la prima cosa da sottolineare è che la maggior parte delle modifiche simultanee, in particolare su documenti più lunghi, riguardano diverse sezioni del testo. Di conseguenza, notando quale revisione gli Utenti A e B hanno acquisito, possiamo fare una fusione a tre vie, come dettagliato da Bill Ritcher di Guiffy Software . Un'unione a tre vie può identificare la posizione in cui le modifiche sono state apportate dall'originale e, a meno che non si scontrino, può fondere silenziosamente entrambe le modifiche in un nuovo articolo. Idealmente, a questo punto eseguire l'unione e mostrare all'utente B il nuovo documento in modo che possa scegliere di rivederlo ulteriormente.

Risoluzione delle collisioni: Questo ti lascia con lo scenario quando entrambi gli editor hanno modificato la stessa sezione. In questo caso, unisci tutto il resto e offri il testo delle tre versioni all'utente B, ovvero includi l'originale, con la versione dell'utente A nella casella di testo o dell'utente B. Tale scelta dipende dal fatto che si pensi che il valore predefinito debba essere quello di accettare l'ultimo (l'utente fa clic su Salva per conservare la propria versione) o forzare l'editor a modificare due volte per ottenere le modifiche (devono applicare nuovamente le modifiche all'editor A versione della sezione).

L'uso della fusione a tre vie in questo modo evita i blocchi, che sono molto difficili da gestire bene sul web (per quanto tempo si lascia che abbiano il blocco?), e lo scenario aggravante 'che potresti voler guardare di nuovo' , che funziona bene solo per le risposte in stile forum. Mantiene anche lo stile post-risposta del Web.

Se vuoi aggiungere un po 'Ajax, unisci dinamicamente in 3 direzioni la versione dell'utente A nella versione dell'utente B mentre la stanno modificando e avvisale. Ora sarebbe impressionante.

Answer 3

In Mediawiki, il server accetta la prima modifica, quindi quando viene salvata la seconda modifica viene visualizzata una pagina di conflitti, quindi la seconda persona unisce le due modifiche. Vedi Wikipedia: Guida: modifica dei conflitti

Answer 4

L'uso di un meccanismo di blocco sarà probabilmente il più facile da implementare. A ciascun articolo potrebbe essere associato un campo di blocco e un tempo di blocco. Se il tempo di blocco supera un valore impostato, il blocco verrà considerato non valido e rimuoverlo quando si verifica l'articolo per la modifica. È inoltre possibile tenere traccia dei blocchi aperti e rimuoverli alla chiusura della sessione. Dovresti anche implementare un po 'di controllo della concorrenza nel database (timestamp autogenerati, forse) in modo da poter assicurarti di controllare un aggiornamento alla versione che hai estratto, nel caso in cui due persone fossero in grado di modificare il articolo allo stesso tempo. Solo quello con la versione corretta sarebbe in grado di controllare con successo in una modifica.

Potresti anche essere in grado di trovare un motore delle differenze che potresti semplicemente usare per costruire le differenze, anche se visualizzarle in un editor wiki può essere problematico - in realtà visualizzare le differenze è probabilmente più difficile che costruire il diff. Farebbe affidamento sul sistema di controllo delle versioni per rilevare quando è necessario rifiutare una modifica ed eseguire una diff.

Answer 5

In Gmail, se stiamo scrivendo una risposta a un'e-mail e qualcun altro invia una risposta mentre la stiamo ancora digitando, viene visualizzato un popup che indica che esiste un nuovo aggiornamento e l'aggiornamento stesso viene visualizzato come un altro post senza ricaricare la pagina . Questo approccio si adatterebbe alle tue esigenze e se puoi usare Ajax per mostrare il post esatto con un link a diff di ciò che è stato appena aggiornato mentre l'utente B è ancora impegnato a digitare la sua voce sarebbe fantastico.

Answer 6

Come hanno detto Ravi (e altri), è possibile utilizzare un approccio AJAX e informare l'utente quando è in corso un'altra modifica. Quando viene inviata una modifica, è sufficiente indicare le differenze testuali e consentire al secondo utente di capire come unire le due versioni.

Tuttavia, vorrei aggiungere qualcosa di nuovo che potresti provare in aggiunta a quello: Apri una finestra di chat tra gli editor mentre stanno facendo le loro modifiche. Per esempio, potresti usare qualcosa come embedded Gabbly .
& nbsp;
& nbsp;
La migliore risoluzione dei conflitti è il dialogo diretto, dico.

Answer 7

Il tuo problema (aggiornamento perso) viene risolto al meglio usando Optimistic Concurrency Control .

Una implementazione consiste nell'aggiungere una colonna versione in ciascuna entità modificabile del sistema. Alla modifica dell'utente si carica la riga e si visualizza il modulo HTML sull'utente. Un campo nascosto fornisce la versione, diciamo 3 . La query di aggiornamento deve essere simile a:

update articles set ..., version=4 where id=14 and version=3;

Se le righe restituite sono 0, qualcuno ha già aggiornato l'articolo 14. Tutto quello che devi fare è come gestire la situazione. Alcune soluzioni comuni:

1. vince l'ultimo commit
2. il primo commit vince
3. unisci aggiornamenti in conflitto
4. lascia decidere all'utente

Invece di una versione incrementale int / long puoi utilizzare un timestamp ma non è consigliato perché:

  

il recupero dell'ora corrente dalla JVM non è necessariamente sicuro in un ambiente cluster, in cui i nodi potrebbero non essere sincronizzati con l'ora.

(citazione da Java Persistence with Hibernate )

Altre informazioni nella hibernate documentazione .

Answer 8

Nel mio ufficio, abbiamo una politica secondo cui tutte le tabelle di dati contengono 4 campi:

• CreatedBy
• CreatedDate
• LastUpdateBy
• LASTUPDATEDATE

In questo modo c'è una bella pista di controllo su chi ha fatto cosa nei registri, almeno più recentemente.

Ma, soprattutto, diventa abbastanza facile confrontare LastUpdateDate del record corrente o modificato sullo schermo (richiede di memorizzarlo sulla pagina, in un cookie, qualunque sia, con il valore nel database. Se i valori non abbinare, puoi decidere cosa fare da lì.