Esta conversación se ha mantenido en el chat de Skype del canal de Mod-Harbour, y como me ha parecido sumamente interesante, he querido transcribirla aqui
Victor, 7:25Hola.
Aprovecho este foro para lanzar una cuestión y ver sus opiniones, ya que este grupo es de modHarbour el sentido del mismo es la utilización de harbour como backend para la web ( y los diferentes temas que vayan surgiendo al respecto ) Una de las cosas que más se realiza es acceder a los datos, independientemente de su origen, y me gustaría saber su opinión o como gestionan el bloqueo de registros para su edición. Me explico; el usuario A abre una ficha para modificarla, la modifica y la guarda en la base de datos. Por supuesto, mientras la está editando no tiene la conexión a la BD abierta ni el registro bloqueado. Mientras el Usuario B hace lo mismo. Como controlan esto? una tabla con los registros que se están modificando? una marca en el registro que se está modificando? Comprobar cuando se guarda el registro si ha sido modificado por otro usuario después del inicio de la edición? utilizan solo un control o varios a la vez?
Salud!
Paquito, 10:19Hola Víctor. Respondiendo a tu cuestión.
En su día me planteé exactamente el mismo problema. Hablo de no menos de 10 años.
Hasta donde yo sabía en los foros que habitualmente transitaba (fwh/ Harbour) nunca se habia preguntado por esto ni se habia planteado el problema. Hasta cierto punto es logico, es un problema que no es ni de Fwh ni de Harbour, es un "problema" de técnica programática. Así las cosas pensé y desarrollé la siguiente idea:
- Los documentos editables tendrán un botón de edición, es decir, el usuario accederá a verlos pero sólo serán editables cuando en el momento de tenerlos en pantalla pulsen en el botón modificar. Esto es importante por lo que viene a continuación
- cuando un primer usuario pulsa el botón modificar entonces bloquea el documento y el resto de usuarios sólo pueden ver pero no modificar. En los listados aparece un bitmap a los usuarios indicando que está bloqueado y qué programa y quién lo tiene bloqueado. El bloqueo se realiza con tecnica que impida que cualquier cuelgue en la aplicacion deje el documento en modo edicion, es decir, no grabar los bloqueos en una tabla.
Y hasta ahora. Estoy abierto a mejoras
Victor, 11:32@Paquito gracias por tu planteamiento. Cuando dices que bloquea el documento, te refieres a que tienes un campo en la tabla tipo 'locked' ?
Paquito, 11:35no. eso es ruina Victor. Como comenté ese sistema dejará en caso cuelgue documentos bloqueados. Desarrollé un sistema basado en handle, porque dadme un handlevy moveré el mundo. Si tienes interés puedo profundizar
Victor, 11:37Y como saben los usuarios que está bloqueado?
Paquito, 11:42Utilizo tecnica handle. Realmente un sistema basado en el handle devuelto por FCreate.
Cuando el doc1 se bloquea creo archivo blq_doc1.txt conteniendo info de programa y usuariio. Si el file blq_doc1.txt no existe o no puede abrirse en exclusivo es que doc1 está bloqueado.
Esa es la técnica handle... Cuando el programa crashea los archivos dejan automáticamente de estar en usoEs el S.O. el que gestiona
Victor, 11:44Ok, es buena, pero en un entorno web, no se tendría acceso a estos ficheros del disco. Creo.
Cristobal. Hoy a las 11:44Yo creo que sí Victor,
Victor 11:48Como lo harías? Por API?Me refiero a que cuando le pides, por ejemplo, una lista de documentos, para devolverla con la marca de si está bloqueado o no, hay que tomar una lista de los ficheros .txt que hayan y procesarlos con la lista de documentos, correcto?
Paquito, 11:55Si la pregunta es para mi respondo:
Si asi lo hago y funcionando en desktop 100% Ni un problema en no menos de 10 añosLa tecnica vale para bloquear y compartir cualquier cosa sin miedo a crashes
Victor, 11:58Exacto @Paquito, a eso me refiero. En un entorno web, haces la petición de los datos, te los devuelve, los muestras por pantalla (edición) pero no puedes tienen un fichero abierto en el disco mientras editas, en ese momento puedes hasta estar totalmente desconectado. Pero igualmente estás editando.Para Desktop es una muy buena opción, pero no sé cómo se aplicaría en un entorno web.
Pedro, 12:06Para web yo he utilizado un campo timestamp que se actualiza cada vez que se modifica un registro.
Al leer para edición me traigo también el timestamp y al recibir el submit del formulario primero compruebo si el timestamp a cambiado.
En caso de que no cambie, quiere decir que nadie lo ha editado y simplemente lo actualizo.
Si está cambiado hay que decidir qué haces;
- ¿ Le devuelves al nevegador el formulario indicándole los campos en conflicto.?
- ¿Le avisas del conflicto y que vuelva a editarlo?
- ¿ Admites la edición y guardas en algún log el conflicto ?
- ¿Cualquier otra opción ?
Victor, 12:09Gracias @Pedro. Este sistema lo he planteado también. Lo veo válido para web.
Cristobal, @Victor , Evidentemente si podemos establecer ahora las estructuras, creo que una buena opción a tener en cuenta, es la de añadir a nuestras estructuras de bases de datos un campo de tipo [ = ] ModTime, que se actualiza automáticamente por parte de harbour cada vez que el registro es modificado. Consultando dicho campo tenemos la información de si ha sido modificado o no.Para mí, últimamente este tipo de campos para trabajar con DBFs es imprescindibley creo que se puede hacer compatible si utilizas otras BBDD
Victor, 12:24Exacto. Serían updated_at y created_at (copia directa de eloquent)
Cristobal, 12:25Por ahí van los tiros, evidentemente, el enfoque es el de darle amplitud de miras teniendo en cuenta el ORM que estás desarrollandoEn el caso de no poder ( o simplemente ser complicado en ese momento ) modificar las estructuras de los DBFs que ya tienes funcionando, tenemos otras posibles técnicas a nuestra disposición
Paquito, 12:27@PedroVictor Casajuana Mas Casajuana Mas, Hoy a las 12:09Válido para web pero ineficiente IMHO porque sólo se sabe al final. Un usuario un cuarto de hora modificando un pedido y luego se lo rechaza el sistema. Es para blasfemar en arameo12:28Tienes toda la razón, @Paquito, ahí es donde entraría un timer para consultar de vez en cuando el estado de ese campo y combinarlo con tu técnica del "bitmap" o mensajito, no?
Victor, 12:32En este caso se podría recurrir a sockets, como hace Google Drive, y mostrar los usuarios que están dentro. Ya sería ir a otro nivel.
Cristobal, 12:34Sin tener que irnos tan lejos, considero el tema que estamos hablando tan sumamente importante como para entender que para dar una cumplida solución ( digamos al 99% ) hemos de asumir utilizar varias técnicas combinadas ( al menos 2 )
Victor, 12:34Exacto
Cristobal, 12:36Yo utilizo los ModTime, evidentemente, y un sistema de logs. Pero, eso sí, que sea transparente para mí: que se lo "curre" harbour.
Paquito, 12:41Aunque hable de .dbfs esto que digo valdriía para toda base de datos:
Otro sistema que nunca indagué ni usé fue explotar la capacidad de Harbour para hacer multiples bloqueos en la misma .dbf.
Imaginaros/ imagínense que tenemos una .dbf con documento_tipo documento_numero documento_usuario. Si cada vez que hacemos una entrada (o buscamos) y bloqueamos, quizá podría hacer el mismo papel que los archivos blq_.txt que propuse anteriormente
Cristobal, 12:42Harbour también dispone del tipo [ ^ ] RowVers 8 Row version number; modification count of this record
Paquito, 12:42---
Asi pues el sistema, para que sea lo más parecido a optimo, tiene que ser:
1 - Resistente a crashes y
2 - Debe avisar del bloqueo PREVIAMENTE
Cristobal, 12:43Ahí es donde se cae mi planteamiento tal y como lo he hecho, en el punto 2
Paquito, 12:45Yo lo que digo es tener una .dbf bloqueos.dbf, aunque la App tire de mySql da igual, lo haremos en una .dbf sacando provecho de la posibilidad de bloquear multiples registros bloqueados en una misma .dbf que tiene harbourBloqueos.dbf sustituiria a mi sistema de bloqueos por handle.
Aunque nunca usé bloqueos multiples en Harbour, en teoria deberia funcionar y valdria, por supuesto, tanto para desktop como para web
Paquito, 12:53---
Se podria tener un .dbf de bloqueos por cada tipo de documento. Asi blq_Albaranes.dbf seria la gestionadora de bloqueo de Albaranes.dbf blq_Pedidos.dbf lo mismo de Pedidos... Mi gusto es tener todo en la misma .dbf asi que me gusta mas un bloqueos.dbf separado por tipo de documento. De esta manera tambien se puede usar para otro tipo de documentos o situaciones. Se podria bloquear por ejemplo contadores, antes de dar contador, se bloquea. Cuando se genera una hoja de carga, que es un documento no fisico, sino que se compone al vuelo a partir de otros documentos, se puede validar que no haya ya uno generado. Se puede bloquear asimismo que dos usuarios no entren a la vez a una determinada opcion del menu.
Es decir el sistema de bloqueos va mucho mas alla de la mera edicion de documentos.
dbRLock() -> Bloqueo de multiples registros en una misma work area (por el mismo usuario, evidentemente)
https://www.itlnet.net/programming/prog ... 2e977.html
Hay dos tipos de personas: las que te hacen perder el tiempo y las que te hacen perder la noción del tiempo
El secreto de la felicidad no está en hacer lo que te gusta, sino en que te guste lo que haces