Como desarrollador de aplicaciones, es probable que nunca tengas que hacer nada espec\u00edfico en la aplicaci\u00f3n para resolver conflictos, ya que el sistema de resoluci\u00f3n de conflictos por defecto se encargar\u00e1 autom\u00e1ticamente de ello. Sin embargo, si lo necesitas, tienes la opci\u00f3n de ser notificado de los conflictos y tomar las medidas oportunas. Este post discutir\u00e1 los fundamentos de c\u00f3mo los conflictos de documentos son manejados autom\u00e1ticamente en Couchbase Mobile 2.0 usando el \"resoluci\u00f3n autom\u00e1tica de conflictos<\/em>\" o \"sin conflictos <\/em>\".<\/p>\n <\/p>\n <\/p>\n Este post asume que usted est\u00e1 familiarizado con la arquitectura de la pila de Couchbase Mobile que incluye el Couchbase Lite<\/a> base de datos integrada para sus clientes m\u00f3viles, el Pasarela de sincronizaci\u00f3n<\/a> y Servidor Couchbase<\/a>. Si eres nuevo en la plataforma, te recomiendo que empieces por estos recursos<\/a>.<\/p>\n Si a\u00fan no lo ha hecho, le recomendamos que lea esto antes. desmitificar la resoluci\u00f3n de conflictos post<\/a> que discute los fundamentos de c\u00f3mo se maneja la resoluci\u00f3n de conflictos en modo \"no libre de conflictos\" en Couchbase Mobile, incluyendo una visi\u00f3n general del sistema de Control de Concurrencia Multi-Versi\u00f3n (MVCC).<\/p>\n Para entender el proceso de resoluci\u00f3n de conflictos, tendr\u00edas que tener una comprensi\u00f3n b\u00e1sica de c\u00f3mo se almacenan los documentos. En Couchbase Mobile, a cada documento se le asigna un \u00fanico ID de revisi\u00f3n generado por el sistema o revID<\/em>. Este identificador se a\u00f1ade al identificador del documento, que es el mismo para todas las revisiones. Cada cambio en un documento, ya sea una modificaci\u00f3n o una eliminaci\u00f3n, se trata como una nueva revisi\u00f3n del documento y, por tanto, se le asigna un nuevo ID de revisi\u00f3n.<\/p>\n Adem\u00e1s, cada revisi\u00f3n de documento tiene un \"generationID<\/em>\"asociada a ella. La primera vez que se crea un documento, se crea una revisi\u00f3n con un \"generationID<\/em>\" de 1. Cada actualizaci\u00f3n de revisi\u00f3n posterior incrementar\u00e1 este n\u00famero.<\/p>\n Cada vez que se va a realizar un cambio (edici\u00f3n o eliminaci\u00f3n) en un documento existente, el autor debe incluir el ID de revisi\u00f3n de la revisi\u00f3n actual del documento que se est\u00e1 actualizando. Se crea una nueva revisi\u00f3n para el cambio y se a\u00f1ade como nodo hijo a la revisi\u00f3n actual que se estaba actualizando, dando lugar a un \u00c1rbol de Revisi\u00f3n para el documento.<\/p>\n NOTA \"revID\"<\/em> debe ser tratado por la aplicaci\u00f3n como un objeto opaco y la aplicaci\u00f3n no debe intentar generar el objeto \"revID\"<\/em>.<\/p>\n A alto nivel, un conflicto se produce cuando varios redactores realizan cambios en la misma revisi\u00f3n principal de un documento.<\/p>\n La siguiente ilustraci\u00f3n describe un escenario en el que una aplicaci\u00f3n est\u00e1 actualizando una revisi\u00f3n de documento en memoria mientras que la misma revisi\u00f3n se est\u00e1 actualizando como resultado de una replicaci\u00f3n pull. La siguiente ilustraci\u00f3n describe una situaci\u00f3n en la que dos clientes introducen cambios en la misma revisi\u00f3n del documento. En \"Sin conflictos<\/em> el Sync Gateway rechaza todas las actualizaciones conflictivas. Los conflictos se resuelven autom\u00e1ticamente en el momento en que se crea, actualiza o elimina el documento. Cada documento en Couchbase Lite 2.0 est\u00e1 asociado a un \"resoluci\u00f3n de conflictos\"<\/em> que se ejecuta si se produce un conflicto cuando se intenta Hay dos pol\u00edticas de control de concurrencia soportadas por Couchbase Lite.<\/p>\n Esta es tambi\u00e9n la pol\u00edtica de resoluci\u00f3n de conflictos por defecto. En este caso, siempre gana la \u00faltima actualizaci\u00f3n de la base de datos.<\/p>\n Cuando llame Este es un ejemplo de la llamada en swift.<\/p>\n Los siguientes ejemplos deber\u00edan aclarar las implicaciones de esta pol\u00edtica<\/p>\n Aunque anticipamos que la pol\u00edtica de control de concurrencia por defecto de \"la \u00faltima escritura gana\" deber\u00eda funcionar para la mayor\u00eda de los casos, puede anular el comportamiento por defecto especificando que desea ser notificado en caso de conflicto al guardar el documento. Esto puede hacerse incluyendo la opci\u00f3n ControlConcurrente<\/em> como parte de la solicitud de almacenamiento.<\/p>\n Un valor de retorno La forma de manejar los conflictos depende de la sem\u00e1ntica de la aplicaci\u00f3n. Aqu\u00ed hay ejemplos de c\u00f3mo se puede manejar en swift (que puede ser f\u00e1cilmente mapeado a otros lenguajes)<\/p>\n Este es un ejemplo de c\u00f3mo fusionar las revisiones en conflicto. Una vez m\u00e1s, la forma de hacerlo depende enteramente de su aplicaci\u00f3n. Esto pretende ser una implementaci\u00f3n de referencia sobre c\u00f3mo usted podr\u00eda<\/em> manejarlo.<\/p>\n Esta opci\u00f3n es efectivamente la misma que la pol\u00edtica de concurrencia por defecto de \"las escrituras siempre ganan\". Excepto que en este caso, se examina el contenido del documento actualmente guardado y luego se determina si se debe forzar el guardado utilizando un comando En este caso, podr\u00eda examinar el contenido del documento guardado actualmente y, a continuaci\u00f3n, determinar que prefiere conservar la versi\u00f3n guardada actualmente del documento.<\/p>\n Dado que la pol\u00edtica de resoluci\u00f3n de conflictos por defecto en Por lo tanto, si desea asegurarse de que no actualiza inadvertidamente un documento existente, debe especificar el valor \"ConcurrenyControl<\/em> argumento con Es muy similar a la opci\u00f3n 3 especificada anteriormente, salvo que en este caso no es necesario examinar el contenido actual del documento. Un fallo de conflicto implica que ya existe un documento con Id.<\/p>\n Este es un ejemplo en Swift<\/p>\n En este modo, la pasarela de sincronizaci\u00f3n rechaza las revisiones que causan un conflicto con un Error HTTP 409, asegurando as\u00ed que no hay revisiones conflictivas en la base de datos. Los conflictos se gestionan en el lado del cliente durante una replicaci\u00f3n pull.<\/p>\n Durante una replicaci\u00f3n pull, si el cliente detecta un conflicto, \u00e9ste se resuelve utilizando los siguientes criterios deterministas<\/p>\n <\/p>\n A continuaci\u00f3n, examinamos los casos durante la Replicaci\u00f3n Pull.<\/p>\n La rama de servidores es la ganadora<\/strong><\/p>\n NOTA<\/strong>: Como usted ha observado, los conflictos se resuelven en Couchbase Lite durante una replicaci\u00f3n pull. La implicaci\u00f3n de esto es que si el replicador est\u00e1 configurado para ser s\u00f3lo un replicador de empuje, a continuaci\u00f3n, la vista de Couchbase Lite de los datos divergentes de Sync Gateway (ya que algunos de los intentos de CBL escribe fallar\u00eda w \/ 409). Por lo tanto, si prev\u00e9 que se produzcan conflictos, se recomienda que el replicador de Couchbase Lite se configure en modo push-pull cuando se utilice en modo Conflict Free.<\/p>\n <\/p>\n El modo \"Sin conflictos\" de Sync Gateway se puede configurar a trav\u00e9s de permitir_conflictos<\/a>\u00a0en el archivo de configuraci\u00f3n de Sync Gateway. Debe tener el valor \"falso<\/em>\" para habilitar el modo libre de conflictos. Tambi\u00e9n debe tenerse en cuenta que, independientemente de la configuraci\u00f3n de esta propiedad, no habr\u00e1 revisiones conflictivas a\u00f1adidas a la puerta de enlace de sincronizaci\u00f3n cuando se sincronice con clientes Couchbase Lite 2.0. Ya hemos hablado de ello en la secci\u00f3n sobre Replicaci\u00f3n. La configuraci\u00f3n \"allow_conflicts\" s\u00f3lo tiene implicaciones para clientes no 2.0 y clientes REST API. La siguiente tabla resume las implicaciones<\/p>\n El impacto de la resoluci\u00f3n de conflictos en el tama\u00f1o de la base de datos se trat\u00f3 en detalle en nuestro anterior post sobre Gesti\u00f3n del tama\u00f1o de las bases de datos<\/a>. En el sistema que permit\u00eda conflictos, a medida que crec\u00edan las revisiones en conflicto, el tama\u00f1o del \u00e1rbol de revisiones pod\u00eda crecer hasta afectar al tama\u00f1o de la base de datos. Por eso era importante resolver los conflictos a tiempo. Sync Gateway tiene un Sin embargo, con el modo libre de conflictos, no hay necesidad real de guardar los metadatos correspondientes a las revisiones m\u00e1s antiguas. Esto implica que el Un agradecimiento especial a Pasin Suriyentrakorn<\/a> del equipo de ingenier\u00eda m\u00f3vil por sus comentarios sobre las secciones de Couchbase Lite, a Adam Fraser<\/a>, tambi\u00e9n del equipo de Ingenier\u00eda de M\u00f3viles, por sus comentarios sobre las secciones de Sync Gateway y a Daniel Petersen, del equipo de Ingenier\u00eda de M\u00f3viles, por sus comentarios.<\/p>\n Esta entrada del blog discute c\u00f3mo los conflictos se manejan autom\u00e1ticamente en Couchbase Mobile 2.0. Puedes descargar Couchbase Mobile 2.0 desde nuestro descargas<\/a> p\u00e1gina.<\/p>\n Si tiene alguna pregunta o sugerencia, deje un comentario a continuaci\u00f3n o p\u00f3ngase en contacto conmigo a trav\u00e9s de Twitter en la direcci\u00f3n\u00a0@rajagp<\/a>\u00a0o env\u00edeme un correo electr\u00f3nico a\u00a0priya.rajagopal@couchbase.com<\/a>. En\u00a0Foros de Couchbase<\/a> son otro buen lugar para plantear preguntas.<\/p>\n <\/p>","protected":false},"excerpt":{"rendered":" Document conflicts can occur in distributed environments that support data synchronization, wherein a document can be updated concurrently by one or more writers. This is especially common in mobile environments where unreliable network connections may result in concurrent changes from […]<\/p>","protected":false},"author":1423,"featured_media":10700,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[1815,1821,7667,1810,2366,2201],"tags":[2178,1980,2004,1981],"ppma_author":[8948],"class_list":["post-4832","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-best-practices-and-tutorials","category-couchbase-architecture","category-couchbase-lite","category-couchbase-mobile","category-sync-gateway","category-tools-sdks","tag-concurrency-control","tag-conflict-resolution","tag-couchbase-mobile-2-0","tag-mvcc"],"acf":[],"yoast_head":"\nSupuestos<\/h2>\n
Fondo<\/h2>\n
\u00c1rbol de revisi\u00f3n de documentos<\/h3>\n
![\"\"](\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2017\/05\/revision-tree-latest.png\")
<\/figure>\nC\u00f3mo se producen los conflictos de documentos<\/h2>\n
Conflictos en Couchbase Lite<\/h3>\n
\n![\"\"](\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2018\/03\/cbl_conflict-1.png\")
<\/p>\nConflictos en la pasarela de sincronizaci\u00f3n<\/h3>\n
\n![\"\"](\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2017\/05\/conflict-basics-1.png\")
<\/p>\nResoluci\u00f3n de conflictos en Couchbase Mobile 2.0<\/h2>\n
\nEsto implica que no hay documentos conflictivos almacenados en la base de datos y es efectivamente, \"Sin conflictos<\/em>\". Vamos a ver c\u00f3mo funciona.<\/p>\nResoluci\u00f3n autom\u00e1tica de conflictos en Couchbase Lite 2.0<\/h3>\n
guardar<\/code> o borrar<\/code> un documento. La funci\u00f3n de resoluci\u00f3n de conflictos elige un \"ganador<\/em>\" entre las revisiones en conflicto y este ganador se a\u00f1ade como hijo al \u00e1rbol de revisiones del documento.<\/p>\n![\"\"](\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2018\/01\/conflict-resolver-basics.png\")
<\/figure>\nPol\u00edtica de control de concurrencia<\/h4>\n
La \u00faltima escritura siempre gana (por defecto):<\/strong><\/h5>\n
guardarDocumento<\/code> sin el argumento Control de concurrencia, \u00e9sta es la pol\u00edtica que se aplica por defecto.<\/p>\n let savedDocument = try saveDocument(docToSave)<\/code><\/pre>\n\n
![\"\"](\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2018\/03\/conflict-free-last-write-wins.png\")
<\/figure>\n\n
![\"\"](\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2018\/03\/conflict-free-last-write-wins-on-delete-1.png\")
<\/figure>\nFracasar en el conflicto<\/strong><\/h5>\n
falso<\/code> con un Control de concurrencia <\/em>pol\u00edtica failOnConflict<\/code> indica que el documento guardado fall\u00f3 como resultado de un conflicto. A continuaci\u00f3n examinaremos c\u00f3mo puede gestionar los errores de conflicto.<\/p>\nGesti\u00f3n de fallos en los conflictos<\/h4>\n
\n
do {\r\n var success = false\r\n repeat {\r\n if try db.saveDocument(docToSave, concurrencyControl: .failOnConflict) {\r\n \/\/ save was a success. docToSave is the new saved revision. Proceed as usual\r\n success = true\r\n }\r\n else {\r\n \/\/ Failure on save with failOnConflict mode\r\n \/\/ Handle conflict appropriately\r\n \/\/ First, fetch the current saved version of doc\r\n if let currDoc = db.document(withID: docToSave.id) {\r\n \/\/ Option 1 : Merge the contents of doc1b and currDoc\r\n docToSave = mergeDocument(newDoc: docToSave, currentDoc: currDoc)\r\n }\r\n else {\r\n \/\/ Doc was deleted. Handle appropriately\r\n }\r\n }\r\n \r\n } while (!success)\r\n}\r\ncatch {\r\n print(\"Some other error in saving \\(error)\")\r\n}<\/code><\/pre>\n\r\n\/\/\/ Merges two conflicting versions of CBL document using following criteria\r\n\/\/\/ - Newly added properties are added \r\n\/\/\/ - If we are updating an existing property, that is ignored a property that already exists\r\n\/\/\/\r\n\/\/\/ - Parameter \r\n\/\/\/ - newDoc: The new version of document to be saved\r\n\/\/\/ - currentDoc : The current saved version of the document\r\nfunc mergeDocument(newDoc: Document, currentDoc: Document) -> MutableDocument {\r\n \/\/ 1. Create a resolved mutable document based on the current saved document\r\n let resolved = currentDoc.toMutable()\r\n \r\n \/\/ 2. Add the additional properties that don't already exist\r\n for key in newDoc.keys {\r\n if !resolved.contains(key) {\r\n resolved.setValue(newDoc.value(forKey: key), forKey: key)\r\n }\r\n }\r\n return resolved\r\n}<\/code><\/pre>\n\n
guardarDocumento<\/code>.
\nTenga en cuenta que a\u00fan podr\u00eda correr el riesgo de una condici\u00f3n de carrera en la que el documento podr\u00eda ser actualizado de nuevo antes de guardarlo.<\/p>\ndo {\r\n if try db.saveDocument(docToSave, concurrencyControl: .failOnConflict) {\r\n \/\/ save was a success. docToSave is the new saved revision. Proceed as usual\r\n }\r\n else {\r\n \/\/ Failure on save with failOnConflict mode\r\n \/\/ Handle conflict appropriately\r\n if let currDoc = db.document(withID: docToSave.id) {\r\n \/\/ Option 2: Examine contents of current saved version of doc\r\n \/\/ Force write of document\r\n try db.saveDocument(docToSave)\r\n }\r\n else {\r\n \/\/ Doc was deleted.\r\n \/\/ Option 2: Attempt to do a force write of document to override the delete\r\n try db.saveDocument(docToSave)\r\n }\r\n }\r\n}\r\ncatch {\r\n print(\"Some other error in saving \\(error)\")\r\n}<\/code><\/pre>\n\n
do {\r\n let docToSave = MutableDocument(id: \"docId\")\r\n if !(try db.saveDocument(docToSave, concurrencyControl: .failOnConflict)) {\r\n \/\/ Fetch the current saved version of doc\r\n if let currDoc = db.document(withID: docToSave.id) {\r\n \/\/ Option 3 : Examine contents of doc\r\n \/\/ Current saved doc looks fine. Do nothing\r\n }\r\n else {\r\n \/\/ Doc was deleted. Handle appropriately\r\n }\r\n }\r\n else {\r\n \/\/ save was a success. docToSave is the new saved revision. Proceed as usual\r\n }\r\n}\r\ncatch {\r\n print(\"Some other error in saving \\(error)\")\r\n}\r\n<\/code><\/pre>\nImplicaciones en la creaci\u00f3n de documentos con el mismo Id.<\/h3>\n
guardarDocumento<\/code> es que la \u00faltima escritura siempre gana, si se intenta crear de nuevo un documento con un docId<\/code> que ya existe en la base de datos, seguir\u00e1 adelante y actualizar\u00e1 el documento existente a\u00f1adi\u00e9ndole una nueva revisi\u00f3n.<\/p>\nfailOnConflict<\/code>. Esto devolver\u00e1 un error que podr\u00e1 gestionar adecuadamente.<\/p>\ndo {\r\n let docToSave = MutableDocument(id: \"docId\")\r\n if !(try db.saveDocument(docToSave, concurrencyControl: .failOnConflict)) {\r\n \/\/ Document with Id already exists. Handle appropriately\r\n }\r\n else {\r\n \/\/ save was a success. docToSave is the new saved revision. Proceed as usual\r\n }\r\n}\r\ncatch {\r\n print(\"Some other error in saving \\(error)\")\r\n}<\/code><\/pre>\nModo sin conflictos en Sync Gateway 2.0<\/h3>\n
Replicaci\u00f3n Push<\/h4>\n
![\"\"](\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2018\/01\/conflict-free-push.png\")
<\/figure>\n\n
Replicaci\u00f3n Pull<\/h4>\n
\n
![\"\"](\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2018\/03\/deletes_always_win.png\")
<\/p>\n\n
ID de generaci\u00f3n<\/code>) gana o la revisi\u00f3n con max revID<\/code> gana si las generaciones son iguales. es decir - el revID que ordena m\u00e1s alto en una simple comparaci\u00f3n ASCII. A continuaci\u00f3n se muestra un ejemplo.<\/li>\n<\/ul>\n![\"\"](\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2018\/03\/most_recent_writes_win.png\")
<\/figure>\n![\"\"](\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2018\/03\/conflict-free-pull-server-winner.png\")
<\/figure>\n\n
\n
Rev2-B<\/code>) del servidor es m\u00e1s reciente que la revisi\u00f3n local (Rev2-A<\/code>), se selecciona la revisi\u00f3n del servidor como ganadora. Tenga en cuenta que esto tambi\u00e9n ocurrir\u00eda si la revisi\u00f3n del servidor se borrara.<\/li>\n<\/ol>\n<\/li>\nLa sucursal local es la ganadora<\/strong><\/h5>\n
![\"\"](\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2018\/03\/conflict-free-pull-local-winner.png\")
<\/figure>\n\n
\n
Rev2-B<\/code>) es la m\u00e1s reciente que la revisi\u00f3n del servidor entrante (Rev2-A<\/code>), la revisi\u00f3n local es seleccionada como la ganadora. Tenga en cuenta que esto tambi\u00e9n ocurrir\u00eda si la revisi\u00f3n de la rama local fuera eliminada.<\/li>\n<\/ol>\n<\/li>\nRev3<\/code> que corresponde al contenido de la revisi\u00f3n ganadora, Rev2-B<\/code><\/li>\nConfiguraci\u00f3n del modo libre de conflictos en Sync Gateway<\/h3>\n
![\"allow_conflicts_configuration\"](\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2018\/03\/allow_conflict.png\")
<\/p>\nImpacto del modo libre de conflictos en el tama\u00f1o de las bases de datos<\/h2>\n
l\u00edmite_rev<\/code><\/a> que determina el tama\u00f1o del \u00e1rbol de revisi\u00f3n. La direcci\u00f3n l\u00edmite_rev<\/code> tiene un valor predeterminado de 1000, lo que significa que los metadatos correspondientes a las \u00faltimas 1000 revisiones se almacenan en Sync Gateway antes de ser eliminados. Al establecer la propiedad l\u00edmite_rev<\/code> a un valor grande afectar\u00eda negativamente al tama\u00f1o de la base de datos, era importante no fijarlo a un valor muy bajo. Era importante mantener los metadatos correspondientes a las revisiones m\u00e1s antiguas, ya que eran necesarios para gestionar la resoluci\u00f3n de conflictos; de lo contrario, se corr\u00eda el riesgo de tener un bosque de \u00e1rboles de revisiones desconectados para un documento. As\u00ed que el valor m\u00ednimo permitido de l\u00edmite_rev<\/code> es 20.<\/p>\nl\u00edmite_rev<\/code> podr\u00eda ser s\u00f3lo 1. Esto implica que s\u00f3lo se almacena la \u00faltima revisi\u00f3n\/activa. Esto supone un gran ahorro en el tama\u00f1o de la base de datos.<\/p>\nAgradecimientos<\/h2>\n
\u00bfQu\u00e9 sigue?<\/h2>\n