¿Qué puedo hacer para evitar conflictos de escritura en un sitio web de estilo wiki?

Question

En un sitio web de estilo wiki, ¿qué puedo hacer para prevenir o mitigar conflictos de escritura-escritura ¿aún permite que el sitio se ejecute rápidamente y mantiene el sitio fácil de usar?

El problema que preveo es este:

1. El usuario A comienza a editar un archivo
2. El usuario B comienza a editar el archivo
3. El usuario A termina de editar el archivo
4. El usuario B termina de editar el archivo y sobrescribe accidentalmente todas las ediciones del usuario A

He aquí algunos enfoques que se me ocurrieron:

• Tengo algún tipo de sistema de check-out / check-in / lock (aunque no sé cómo evitar que las personas mantengan un archivo desprotegido " demasiado largo " ;, y no quiero que los usuarios se sientan frustrados al no estar permitido para realizar una edición)
• Tenga algún tipo de sistema diff que muestre otros cambios realizados cuando un usuario los confirma. y permite algún tipo de fusión (pero me preocupa que esto sea difícil de crear y que el sitio sea "demasiado difícil de usar")
• Notificar a los usuarios sobre ediciones simultáneas mientras están realizando sus cambios (¿algún tipo de AJAX?)

¿Alguna otra manera de ir a esto? ¿Algún ejemplo de sitios que implementen este pozo?

Answer 1

Recuerde el número de versión (o ID) del último cambio. Luego lea la entrada antes de escribirla y compare si esta versión sigue siendo la misma.

En caso de conflicto, informe al usuario que estaba intentando escribir la entrada que se modificó mientras tanto. Apóyalo con una diferencia.

La mayoría de los wikis lo hacen de esta manera. MediaWiki , Usemod , etc .

Answer 2

Fusión de tres vías: Lo primero que hay que señalar es que la mayoría de las ediciones simultáneas, en particular en documentos más largos, se refieren a diferentes secciones del texto. Como resultado, al observar qué revisión adquirieron los Usuarios A y B, podemos hacer una combinación de tres vías, como se detalla en Bill Ritcher de Guiffy Software . Una combinación de tres vías puede identificar dónde se realizaron las ediciones a partir del original y, a menos que entren en conflicto, puede fusionar ambas ediciones en un artículo nuevo. Idealmente, en este punto, realice la combinación y muestre a la Usuario B el nuevo documento para que pueda elegir revisarlo más a fondo.

Resolución de colisión: Esto te deja con el escenario cuando ambos editores han editado la misma sección. En este caso, combine todo lo demás y ofrezca el texto de las tres versiones al Usuario B, es decir, incluya el original, ya sea con la versión del Usuario A en el cuadro de texto o la del Usuario B. La elección depende de si cree que el valor predeterminado debería ser aceptar la última (el usuario solo hace clic en Guardar para conservar su versión) o forzar al editor a editar dos veces para que entre sus cambios (tienen que volver a aplicar sus cambios a los editores A). versión de la sección).

El uso de la combinación de tres vías como esta evita los bloqueos, que son muy difíciles de manejar bien en la web (¿cuánto tiempo les dejas tener el candado?), y el escenario agravante de "es posible que quieras volver a mirar" , que solo funciona bien para respuestas tipo foro. También conserva el estilo posterior a la respuesta de la web.

Si desea agregar un poco al Ajax, fusione de forma dinámica en 3 vías la versión del Usuario A en la versión del Usuario B mientras lo están editando , y notifíquelos. Ahora eso sería impresionante.

Answer 3

En Mediawiki, el servidor acepta el primer cambio, y luego, cuando se guarda la segunda edición, aparece una página de conflictos, y luego la segunda persona fusiona los dos cambios. Consulte Wikipedia: Ayuda: Editar conflictos

Answer 4

El uso de un mecanismo de bloqueo será probablemente el más fácil de implementar. Cada artículo podría tener un campo de bloqueo asociado y un tiempo de bloqueo. Si el tiempo de bloqueo superó algún valor establecido, consideraría que el bloqueo no es válido y lo eliminará al revisar el artículo para su edición. También puede realizar un seguimiento de los bloqueos abiertos y eliminarlos en el cierre de sesión. También necesitaría implementar algún control de concurrencia en la base de datos (marcas de tiempo autogeneradas, tal vez) para asegurarse de que está revisando una actualización de la versión que verificó, en caso de que dos personas pudieran editar el Artículo al mismo tiempo. Solo el que tenga la versión correcta podrá registrar correctamente una edición.

También puedes encontrar un motor de diferencias que puedas usar para construir diferencias, aunque mostrarlas en un editor de wiki puede ser problemático; en realidad, mostrar las diferencias es probablemente más difícil que construir la diferencia. Confiaría en el sistema de control de versiones para detectar cuándo debe rechazar una edición y realizar una diferencia.

Answer 5

En Gmail, si estamos escribiendo una respuesta a un correo y alguien más envía una respuesta mientras aún la estamos escribiendo, aparece una ventana emergente que indica que hay una nueva actualización y que la actualización aparece como otra publicación sin una recarga de página. . Este enfoque se adaptaría a sus necesidades y si puede usar Ajax para mostrar la publicación exacta con un enlace a la diferencia de lo que se acaba de actualizar mientras el Usuario B aún está ocupado escribiendo su entrada, sería genial.

Answer 6

Como Ravi (y otros) han dicho, podría usar un enfoque AJAX e informar al usuario cuando haya otro cambio en curso. Cuando se envíe una edición, simplemente indique las diferencias textuales y deje que el segundo usuario resuelva cómo fusionar las dos versiones.

Sin embargo, me gustaría agregar algo nuevo que podría probar además de eso: abra un cuadro de diálogo de chat entre los editores mientras hacen sus ediciones. Podrías usar algo como Gabbly incrustado para eso, por ejemplo.
& nbsp;
& nbsp;
La mejor resolución de conflictos es el diálogo directo, digo.

Answer 7

Su problema (actualización perdida) se resuelve mejor usando Control de concurrencia optimista .

Una implementación es agregar una columna versión en cada entidad editable del sistema. En la edición de usuario, carga la fila y muestra el formulario html en el usuario. Un campo oculto da la versión, digamos 3 . La consulta de actualización debe tener un aspecto similar al siguiente:

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

Si las filas devueltas son 0, entonces alguien ya ha actualizado el artículo 14. Todo lo que necesita hacer es cómo lidiar con la situación. Algunas soluciones comunes:

1. últimas confirmaciones ganadas
2. primeras confirmaciones ganadas
3. fusionar actualizaciones conflictivas
4. deja que el usuario decida

En lugar de una versión int / long incremental, puede usar una marca de tiempo pero no se sugiere porque:

  

la recuperación de la hora actual de la JVM no es necesariamente segura en un entorno agrupado, donde los nodos pueden no estar sincronizados en el tiempo.

(cita de Persistencia de Java con Hibernate )

Más información en documentación de hibernación .

Answer 8

En mi oficina, tenemos una política de que todas las tablas de datos contienen 4 campos:

• CreatedBy
• CreatedDate
• LastUpdateBy
• LastUpdateDate

De esa manera, hay una buena pista de auditoría sobre quién ha hecho qué en los registros, al menos la más reciente.

Pero lo más importante es que resulta bastante fácil comparar la Fecha de Actualización del Registro actual o editado en la pantalla (requiere que lo almacene en la página, en una cookie, lo que sea, con el valor en la base de datos. Si los valores no coinciden, puede decidir qué hacer desde allí.