Re: [grupo abanq] Compilación de correos para abanq@googlegroups.com - 1 mensaje en 1 tema
31 views
Skip to first unread message
Juanjo Algaz
Nov 17, 2011, 12:40:09 PM11/17/11
to ab...@googlegroups.com
No te ofendas, pero seguir el video es una tortura visual.
Por otro lado, y lo que voy viendo, es que si se modifica un objeto que estás modificando tú también, el sistema indica mediante un mensaje que el objeto ha sido modificado mientras tu lo editabas, con lo que puedes guardar o pegar una voz en la oficina a ver quién hos...as ha modificado el pedido, cliente, . . . (no es profesional para nada, pero por lo menos te avisa)
Lo correcto es que no lo permitiera modificar hasta que lo suelte el primero que lo abrió en modo edición.
Un saludo
Juanjo A
www.malagatic.com
Tutoriales, formación, desarrollo
El 17/11/11 17:58, ab...@googlegroups.com escribió:
Por otro lado, y lo que voy viendo, es que si se modifica un objeto que estás modificando tú también, el sistema indica mediante un mensaje que el objeto ha sido modificado mientras tu lo editabas, con lo que puedes guardar o pegar una voz en la oficina a ver quién hos...as ha modificado el pedido, cliente, . . . (no es profesional para nada, pero por lo menos te avisa)
Lo correcto es que no lo permitiera modificar hasta que lo suelte el primero que lo abrió en modo edición.
Un saludo
Juanjo A
www.malagatic.com
Tutoriales, formación, desarrollo
El 17/11/11 17:58, ab...@googlegroups.com escribió:
Grupo: http://groups.google.com/group/abanq/topics
- Probando Openerp y .... [1 actualización]
juanjiscan <juanj...@gmail.com> Nov 17 05:24AM -0800
... la primera en la frente. Openerp ¡no tiene transacciones!, y eso
crea problemas graves y serios en la consistencia de los datos. Por
ejemplo, un usuario empieza a crear un pedido y mientras lo está
creando, sin que aún lo haya acabado un segundo usuario ¡¡puede
borrarlo!!, y no sólo eso sino que el primer usuario ni se entera
puede seguir creando su pedido (o eso cree) y cuando le da a guardar o
confirmar pedido ¡sorpresa! has perdido todo, eso debe hacerte mucha
gracias despues de estar 15 minutos metiendo lineas de pedidos.
El aislamiento de operaciones, es BÁSICO Y FUNDAMENTAL en un sistema
serio, es decir, un sistema que no garantiza que lo que hace un
usuario está aislado de las interferencias de otros usuarios
(aislamiento de transacciones), directamente debe ir a la basura.
Esto se puede reproducir fácilmente, en un par de minutos, aqui teneis
un video hecho al vuelo sobre este problema:
http://www.youtube.com/watch?v=6dgInhqB_8w
Luego hay otros problemas mas difíciles de ver, pero igual de serios,
como registros huérfanos, duplicación, etc.. que tambien tienen que
ver con el problema de no tener transacciones. Los sistemas
transaccionales, los inventaron por algo, y el que no lo entiende, es
como Unix, está condenado a repetirlo.
Has recibido este mensaje porque estás suscrito al grupo de Google abanq.
--
Puedes realizar una publicación por correo electrónico.
Para cancelar la suscripción a este grupo, envía un mensaje vacío.
Para obtener más opciones, visita este grupo.
Has recibido este mensaje porque estás suscrito a Grupo "abanq" de Grupos de Google.
Si quieres publicar en este grupo, envía un mensaje de correo
electrónico a ab...@googlegroups.com
Para anular la suscripción a este grupo, envía un mensaje a abanq-un...@googlegroups.com
Para obtener más opciones, visita este grupo en http://groups.google.com/group/abanq?hl=es.
No dejes de visitar la web donde estamos compartiendo codigo http://code.google.com/p/abanq-mods/
juanjiscan
Nov 17, 2011, 3:27:38 PM11/17/11
to abanq
Sí, ha sido bastante lamentable ese primer intento :), aquí se ve
mejor:
http://www.youtube.com/watch?v=gubqnaVDyJY
En este caso no te avisa. Pero si así fuera no soluciona nada, no
todos los procesos son interactivos, hay procesos en diferido o en
batch que no tienen porque tener un usuario delante.
Desde mi punto de vista de programador, esto es un verdadero problema
insalvable, porque cuando programo algo que hace consultas sobre
datos, no puedo estar seguro al 100% que esos datos que voy a
modificar o actualizar son fiables y que no voy a interferir con lo
que está haciendo otro usuario u otro proceso.
Un saludo.
On 17 nov, 18:40, Juanjo Algaz <jal...@gmail.com> wrote:
> No te ofendas, pero seguir el video es una tortura visual.
>
> Por otro lado, y lo que voy viendo, es que si se modifica un objeto que
> est�s modificando t� tambi�n, el sistema indica mediante un mensaje que
>
> Un saludo
> Juanjo Awww.malagatic.com
> Tutoriales, formaci�n, desarrollo
>
> El 17/11/11 17:58, ab...@googlegroups.com escribi�:
> > * Probando Openerp y .... <#group_thread_0> [1 actualizaci�n]
>
> > Probando Openerp y ....
> > <http://groups.google.com/group/abanq/t/234ae99560cca325>
>
> > juanjiscan <juanjis...@gmail.com> Nov 17 05:24AM -0800
>
> > ... la primera en la frente. Openerp �no tiene transacciones!, y eso
> > creando, sin que a�n lo haya acabado un segundo usuario ��puede
> > borrarlo!!, y no s�lo eso sino que el primer usuario ni se entera
> > Luego hay otros problemas mas dif�ciles de ver, pero igual de serios,
> > como registros hu�rfanos, duplicaci�n, etc.. que tambien tienen que
>
> > Has recibido este mensaje porque est�s suscrito al grupo de Google abanq.
> > Puedes realizar una publicaci�n por correo electr�nico
> > <mailto:ab...@googlegroups.com>.
> > Para cancelar la suscripci�n a este grupo, env�a
> > <mailto:abanq+un...@googlegroups.com> un mensaje vac�o.
> > Para obtener m�s opciones, visita
> > <http://groups.google.com/group/abanq/topics> este grupo.
>
> > --
> > Has recibido este mensaje porque est�s suscrito a Grupo "abanq" de
> > Grupos de Google.
> > Si quieres publicar en este grupo, env�a un mensaje de correo
> > electr�nico a ab...@googlegroups.com
> > Para anular la suscripci�n a este grupo, env�a un mensaje a
> > abanq-un...@googlegroups.com
> > Para obtener m�s opciones, visita este grupo en
mejor:
http://www.youtube.com/watch?v=gubqnaVDyJY
En este caso no te avisa. Pero si así fuera no soluciona nada, no
todos los procesos son interactivos, hay procesos en diferido o en
batch que no tienen porque tener un usuario delante.
Desde mi punto de vista de programador, esto es un verdadero problema
insalvable, porque cuando programo algo que hace consultas sobre
datos, no puedo estar seguro al 100% que esos datos que voy a
modificar o actualizar son fiables y que no voy a interferir con lo
que está haciendo otro usuario u otro proceso.
Un saludo.
On 17 nov, 18:40, Juanjo Algaz <jal...@gmail.com> wrote:
> No te ofendas, pero seguir el video es una tortura visual.
>
> Por otro lado, y lo que voy viendo, es que si se modifica un objeto que
> el objeto ha sido modificado mientras tu lo editabas, con lo que puedes
> guardar o pegar una voz en la oficina a ver qui�n hos...as ha modificado
> el pedido, cliente, . . . (no es profesional para nada, pero por lo
> menos te avisa)
>
> Lo correcto es que no lo permitiera modificar hasta que lo suelte el
> primero que lo abri� en modo edici�n.
> menos te avisa)
>
> Lo correcto es que no lo permitiera modificar hasta que lo suelte el
>
> Un saludo
> Juanjo Awww.malagatic.com
> Tutoriales, formaci�n, desarrollo
>
> El 17/11/11 17:58, ab...@googlegroups.com escribi�:
> > * Probando Openerp y .... <#group_thread_0> [1 actualizaci�n]
>
> > Probando Openerp y ....
> > <http://groups.google.com/group/abanq/t/234ae99560cca325>
>
> > juanjiscan <juanjis...@gmail.com> Nov 17 05:24AM -0800
>
> > ... la primera en la frente. Openerp �no tiene transacciones!, y eso
> > crea problemas graves y serios en la consistencia de los datos. Por
> > ejemplo, un usuario empieza a crear un pedido y mientras lo est�
> > creando, sin que a�n lo haya acabado un segundo usuario ��puede
> > borrarlo!!, y no s�lo eso sino que el primer usuario ni se entera
> > puede seguir creando su pedido (o eso cree) y cuando le da a guardar o
> > confirmar pedido �sorpresa! has perdido todo, eso debe hacerte mucha
> > gracias despues de estar 15 minutos metiendo lineas de pedidos.
>
> > El aislamiento de operaciones, es B�SICO Y FUNDAMENTAL en un sistema
>
> > serio, es decir, un sistema que no garantiza que lo que hace un
> > usuario est� aislado de las interferencias de otros usuarios
> > (aislamiento de transacciones), directamente debe ir a la basura.
>
> > Esto se puede reproducir f�cilmente, en un par de minutos, aqui teneis
>
> > Luego hay otros problemas mas dif�ciles de ver, pero igual de serios,
> > como registros hu�rfanos, duplicaci�n, etc.. que tambien tienen que
> > ver con el problema de no tener transacciones. Los sistemas
> > transaccionales, los inventaron por algo, y el que no lo entiende, es
> > como Unix, est� condenado a repetirlo.
> > transaccionales, los inventaron por algo, y el que no lo entiende, es
>
> > Has recibido este mensaje porque est�s suscrito al grupo de Google abanq.
> > Puedes realizar una publicaci�n por correo electr�nico
> > <mailto:ab...@googlegroups.com>.
> > Para cancelar la suscripci�n a este grupo, env�a
> > <mailto:abanq+un...@googlegroups.com> un mensaje vac�o.
> > Para obtener m�s opciones, visita
> > <http://groups.google.com/group/abanq/topics> este grupo.
>
> > --
> > Has recibido este mensaje porque est�s suscrito a Grupo "abanq" de
> > Grupos de Google.
> > Si quieres publicar en este grupo, env�a un mensaje de correo
> > electr�nico a ab...@googlegroups.com
> > Para anular la suscripci�n a este grupo, env�a un mensaje a
> > abanq-un...@googlegroups.com
> > Para obtener m�s opciones, visita este grupo en
Victor
Nov 17, 2011, 6:04:22 PM11/17/11
to ab...@googlegroups.com
Estás viendo el comportamiento normal de cualquier aplicación en 3 capas, como las aplicaciones web, donde la conexión está entre el servidor y la base de datos, no entre el programa cliente y la base de datos como AbanQ.
El mensaje de error que te da es porque OpenERP está haciendo "algo" bien, y ese "algo" se llama "bloqueo optimista" (o optimistic locking en inglés), y es una técnica de programación usada en entornos multiusuario. AbanQ no es/era multiusuario, no estaba pensada para un uso simultáneo de varios cientos o miles de usuarios, es/era una aplicación en 2 capas en la que el cliente abría una conexión con base de datos y bloqueaba lo que le daba la gana, mientras que cualquier otro programa multiusuario tiene totalmente prohibido (o muy limitado) realizar bloqueos ya que puedes armar una buena al resto de usuarios, incluso llegar a situaciones de interbloqueo sólo solucionables reiniciando el serivor o matando todas las conexiones causante del bloqueo (algo nada trivial).
Piensa que en una aplicación web, tu transacción dura lo que dura tu petición, es decir, desde que le das a un botón hasta que ves la respuesta, milisegundos, segundos a lo sumo. Después, la misma conexión que usaste en tu transacción pasa a un pool para ser reutilizada por otro usuario, así conseguimos que 100.000 usuarios concurrentes no usen más de 500 o 1000 conexiónes con la BBDD, ya que simultáneamamente, en el mismo segundo, no es probable que haya maś de esas peticiones al servidor. Oracle, por ejemplo, por defecto viene configurado a algo más de 100 conexiones, no me acuerdo exactamente, y te aconsejan que si va a ser usado en un entorno web lo subas a 1000-1500, valores más altos es para auténticas salvajadas de aplicaciones, con miles de peticiones simultáneas.
Cuando un requisito funcional exige que dos usuarios no accedan al mismo tiempo a un registro, entonces no bloqueas toda la transacción sino que "marcas" el registro como bloqueado (con un "select...for update" y un update posterior en Oracle, por ejemplo) en una transacción breve, como siempre lo que dura una única petición HTTP, y todo el que quiera acceder al mismo registro emplea la misma política antes de hacer nada, pero nunca empleas una transacción durante los 5-10 minutos que te lleva realizar una tarea porque no es viable con muchos usuarios.
Además, en AbanQ te iba a pasar algo parecido también en caso de modificaciones concurrentes al mismo registro ya que el último en hacer el commit sobreescribiría los datos del primero, y sin avisos por ningún lado.
Por cierto, estoy pensando muy seriamente pasarme a OpenERP el año que viene, y aunque no me gusta tener un servidor levantado + una base de datos para gestionar mi facturación, es el mejor programa que veo ahora mismo, y el más fácil de configurar y usar (OpenBravo ya es demasiado y encima no ofrece ninguna ventaja sobre OpenERP).
Un saludo
Víctor
El mensaje de error que te da es porque OpenERP está haciendo "algo" bien, y ese "algo" se llama "bloqueo optimista" (o optimistic locking en inglés), y es una técnica de programación usada en entornos multiusuario. AbanQ no es/era multiusuario, no estaba pensada para un uso simultáneo de varios cientos o miles de usuarios, es/era una aplicación en 2 capas en la que el cliente abría una conexión con base de datos y bloqueaba lo que le daba la gana, mientras que cualquier otro programa multiusuario tiene totalmente prohibido (o muy limitado) realizar bloqueos ya que puedes armar una buena al resto de usuarios, incluso llegar a situaciones de interbloqueo sólo solucionables reiniciando el serivor o matando todas las conexiones causante del bloqueo (algo nada trivial).
Piensa que en una aplicación web, tu transacción dura lo que dura tu petición, es decir, desde que le das a un botón hasta que ves la respuesta, milisegundos, segundos a lo sumo. Después, la misma conexión que usaste en tu transacción pasa a un pool para ser reutilizada por otro usuario, así conseguimos que 100.000 usuarios concurrentes no usen más de 500 o 1000 conexiónes con la BBDD, ya que simultáneamamente, en el mismo segundo, no es probable que haya maś de esas peticiones al servidor. Oracle, por ejemplo, por defecto viene configurado a algo más de 100 conexiones, no me acuerdo exactamente, y te aconsejan que si va a ser usado en un entorno web lo subas a 1000-1500, valores más altos es para auténticas salvajadas de aplicaciones, con miles de peticiones simultáneas.
Cuando un requisito funcional exige que dos usuarios no accedan al mismo tiempo a un registro, entonces no bloqueas toda la transacción sino que "marcas" el registro como bloqueado (con un "select...for update" y un update posterior en Oracle, por ejemplo) en una transacción breve, como siempre lo que dura una única petición HTTP, y todo el que quiera acceder al mismo registro emplea la misma política antes de hacer nada, pero nunca empleas una transacción durante los 5-10 minutos que te lleva realizar una tarea porque no es viable con muchos usuarios.
Además, en AbanQ te iba a pasar algo parecido también en caso de modificaciones concurrentes al mismo registro ya que el último en hacer el commit sobreescribiría los datos del primero, y sin avisos por ningún lado.
Por cierto, estoy pensando muy seriamente pasarme a OpenERP el año que viene, y aunque no me gusta tener un servidor levantado + una base de datos para gestionar mi facturación, es el mejor programa que veo ahora mismo, y el más fácil de configurar y usar (OpenBravo ya es demasiado y encima no ofrece ninguna ventaja sobre OpenERP).
Un saludo
Víctor
Has recibido este mensaje porque estás suscrito a Grupo "abanq" de Grupos de Google.
Si quieres publicar en este grupo, envía un mensaje de correo
electrónico a ab...@googlegroups.com
Para anular la suscripción a este grupo, envía un mensaje a abanq-un...@googlegroups.com
Para obtener más opciones, visita este grupo en http://groups.google.com/group/abanq?hl=es.
juanjiscan
Nov 18, 2011, 1:36:44 AM11/18/11
to abanq
Un sistema ERP serio y profesional, primero y ante todo tiene que
garantizar la consistencia y seguridad de los datos y después todo lo
demás; minimizar bloqueos, velocidad (por cierto Openerp es bastante
lento, mucho mas lento que AbanQ), flexibilidad etc.. Y en esto no
caben excusas de que si tengo tropecientosmil usuarios, o que voy a 2,
3 o 4 capas, o que soy un optimista de los bloqueos. No puedes y no
debes sacrificar la consistencia e integridad de los datos para poder
eludir ciertos bloqueos, como muy mal hace OpenErp. Haciendo una
analogía con el tráfico, es como quitar los semáforos y los stops para
intentar evitar atascos. Lo que hace OpenErp es desvestir un santo
para vestir a otro, además no tiene ningún mérito, es el atajo fácil
que puede hacer cualquiera, y crea mas problemas que resuelve.
Por lo tanto para mi AbanQ es una mejor solución porque se adapta
mejor al usuario medio de un ERP. De todos los usuarios que te puedas
encontrar que necesitan un ERP, muy muy pocos te van exigir como
condición indispensable que no exista ningún bloqueo, pero todos,
absolutamente todos, si que te exigirán como condición ineludible que
sus datos sean totalmente fiables y consistentes. Es más, por mi
experiencia he podido comprobar que en la escala de prioridades de un
usuario medio de ERP hay aspectos a los que les dan mucha mas
importacia que poder sufrir algún bloqueo, como por ejemplo la
velocidad de ejecución o la facilidad de uso.
Por cierto, que antes lo preguntaba Juan Jose Pablo en otro mensaje,
Tryton si que lo hace bien, aisla las transacciones y de una forma muy
parecida a AbanQ, a pesar de que Tryton, como fork de OpenErp, también
va a 3 capas y bloqueo optimista, pero además, porque no es excluyente
de lo anterior, maneja correctamente el aislamiento de transacciones.
Incluso utiliza por defecto un modo de aislamiento mas estricto (que
produce mas bloqueos) que AbanQ.
Un saludo
garantizar la consistencia y seguridad de los datos y después todo lo
demás; minimizar bloqueos, velocidad (por cierto Openerp es bastante
lento, mucho mas lento que AbanQ), flexibilidad etc.. Y en esto no
caben excusas de que si tengo tropecientosmil usuarios, o que voy a 2,
3 o 4 capas, o que soy un optimista de los bloqueos. No puedes y no
debes sacrificar la consistencia e integridad de los datos para poder
eludir ciertos bloqueos, como muy mal hace OpenErp. Haciendo una
analogía con el tráfico, es como quitar los semáforos y los stops para
intentar evitar atascos. Lo que hace OpenErp es desvestir un santo
para vestir a otro, además no tiene ningún mérito, es el atajo fácil
que puede hacer cualquiera, y crea mas problemas que resuelve.
Por lo tanto para mi AbanQ es una mejor solución porque se adapta
mejor al usuario medio de un ERP. De todos los usuarios que te puedas
encontrar que necesitan un ERP, muy muy pocos te van exigir como
condición indispensable que no exista ningún bloqueo, pero todos,
absolutamente todos, si que te exigirán como condición ineludible que
sus datos sean totalmente fiables y consistentes. Es más, por mi
experiencia he podido comprobar que en la escala de prioridades de un
usuario medio de ERP hay aspectos a los que les dan mucha mas
importacia que poder sufrir algún bloqueo, como por ejemplo la
velocidad de ejecución o la facilidad de uso.
Por cierto, que antes lo preguntaba Juan Jose Pablo en otro mensaje,
Tryton si que lo hace bien, aisla las transacciones y de una forma muy
parecida a AbanQ, a pesar de que Tryton, como fork de OpenErp, también
va a 3 capas y bloqueo optimista, pero además, porque no es excluyente
de lo anterior, maneja correctamente el aislamiento de transacciones.
Incluso utiliza por defecto un modo de aislamiento mas estricto (que
produce mas bloqueos) que AbanQ.
Un saludo
Juan Jose Pablos
Nov 18, 2011, 2:36:17 AM11/18/11
to ab...@googlegroups.com
El 18/11/11 07:36, juanjiscan escribió:
> Por cierto, que antes lo preguntaba Juan Jose Pablo en otro mensaje,
> Tryton si que lo hace bien, aisla las transacciones y de una forma muy
> parecida a AbanQ, a pesar de que Tryton, como fork de OpenErp, también
> va a 3 capas y bloqueo optimista, pero además, porque no es excluyente
> de lo anterior, maneja correctamente el aislamiento de transacciones.
> Incluso utiliza por defecto un modo de aislamiento mas estricto (que
> produce mas bloqueos) que AbanQ.
>
Es probable que algunos modulos de OpenErp se puedan importar a Tryton
facilmente. Es una posibilidad bastante interesante.
> Por cierto, que antes lo preguntaba Juan Jose Pablo en otro mensaje,
> Tryton si que lo hace bien, aisla las transacciones y de una forma muy
> parecida a AbanQ, a pesar de que Tryton, como fork de OpenErp, también
> va a 3 capas y bloqueo optimista, pero además, porque no es excluyente
> de lo anterior, maneja correctamente el aislamiento de transacciones.
> Incluso utiliza por defecto un modo de aislamiento mas estricto (que
> produce mas bloqueos) que AbanQ.
>
facilmente. Es una posibilidad bastante interesante.
juanjiscan
Nov 18, 2011, 11:29:57 AM11/18/11
to abanq
> Es probable que algunos modulos de OpenErp se puedan importar a Tryton
> facilmente. Es una posibilidad bastante interesante.
Esto debería comentarlo alguien que tenga mas experiencia con Tryton.
> facilmente. Es una posibilidad bastante interesante.
Pero por lo que he visto no parece que pueda ser algo trivial, Tryton
es un fork de hace bastante tiempo y han tomado un camino que difiere
bastante de OpenErp, sobre todo a bajo nivel, y que a mi criterio está
mucho mejor pensado y es mas fiable.
Por ejemplo a nivel de base de datos es mucho mas general, homogéneo y
con una capa de abstracción única, al igual que AbanQ, que te permite
trabajar con MySQL, SQLite, PostgreSQL y potencialmente en cualquier
base de datos SQL si se programa el driver correspondiente. OpenErp
sólo funciona con PostgreSQL y creo que tiene mucho código específico
que sólo puede funcionar en PostgreSQL. En Tryton todos los cursores
parten del objeto Transaction (OpenERP no tiene este objeto ni nada
parecido), que encapsula en transacciones las operaciones que se deben
ejecutar de forma atómica, igual que AbanQ. Bajo ese paradigma debes
tener claro que no se permite acceder a todos los datos en cualquier
momento y de cualquier manera sin importar las consecuencias, como
sucede en OpenErp, sino que hay ciertas cosas que no se pueden hacer,
porque el sistema no te va a dejar hacerlas, para evitar accidentes.
Si los scripts en OpenErp no han sido creados pensando en ese
paradigma, debe ser bastante difícil reprogramarlos para que encajen
en un sistema transaccional estricto.
Reply all
Reply to author
Forward
0 new messages