Migración en caliente (era: Python vs Java C C++)

[Marcos Sánchez Provencio]

Sólo quiero recordar la técnica que usa webware para permitir 
parar/rearrancar la aplicación para obtener las nuevas definiciones de 
manera prácticamente transparente, sin más que definir los métodos 
necesarios para que pickle/unpickle funcione.

En cualquier caso, me parece imprescindible tener un mecanismo parecido 
para poder migrar de servidor, parar/rearrancar por cualquier otro 
motivo, etc. en una aplicación así de seria.

Hernan Foffani wrote:

>Chema Cortes escribio:
>  
>
>>Hernan Foffani escribió:
>>
>>    
>>
>>>mis preguntas eran algo retoricas.  no me refería tanto
>>>al problema técnico en sí (que ya es bastante complejo) si no mas
>>>bien al hecho de mantener toda la aplicación en un estado estable.
>>>
>>>por ej, puede darse el caso que la nueva clase C cambie un
>>>determinado atributo "coleccion" de list a dict. todas las
>>>instancias de C deberían recrear el atributo "coleccion" como dict
>>>con el contenido de las list anteriores.
>>>o si la nueva clase Cuenta cambia el atributo "titular" de la
>>>clase Persona a la clase Cliente, todas las instancias de Persona
>>>que sean atributos de instancias de la clase Cuenta deben
>>>cambiar de clase a Cliente aún cuando tanto Cliente como Persona
>>>no se hayan modificado per se.
>>>      
>>>
>>Me parece que no tienes enfocado correctamente el problema. Los
>>atributos son referencias, sin importar el tipo de dato. Me da igual
>>que titular sea una instancia de Cliente ó una instancia de Persona,
>>puesto que ambas clases coinciden en estructura:
>>    
>>
>
>¡Pero por supuesto que los atributos son referencias!
>¿Por qué presupones que ambas clases (Cliente y Persona)
>coincidirían en su estructura? ¿Que sentido que el progrmador
>pase a utilizar una clase en vez de otra en el atributo
>titular de la clase Cuenta en ese caso?
>Si solo cambia la implementación de algun metodo no voy a
>renombrar la clase por eso. (aun en este ultimo caso habría
>problemas)
>
>Es razonable suponer que si el atributo titular de Cuenta
>cambia de Cliente a Persona o viceversa es porque en el resto
>de la aplicacion se harán invocaciones a metodos o atributos
>diferentes.
>
>  
>
>>....
>>   def SetTitular(self,titular):
>>     self.titular=titular
>>   def GetNombre(self):
>>     return self.titular.nombre
>>    
>>
>
>GetNombre estaria implementada en ambas clases. ese no es
>el problema al que me refiero. (e incluso ahi...)
>
>el problema surge si a partir de la actualizacion necesito
>GetNumCliente (está en Cliente pero no en Persona). Entonces,
> - o cambio de clase a todas las instancias que son atributos
> de Cuenta.
> - o uso try/except por NameError antes de acceder a
> GetNumCliente en TODA la aplicacion.
> - o cualquier otra tecnica parecida a esta ultima.
> ¿y que se supone que haría la aplicacion si no encuentra
> el metodo?
>
>Algun tiempo despues de la actualización de Cuenta, si se
>crearon nuevas instancias de esa clase, habrá algunas instancias
>(las viejas) que tendran como atributo titular objetos Persona
>y otras (las nuevas) atributo titular objetos Cliente.
>Listados, estadisticas, o lo que sea, que barra esas instancias
>darían inconsistencias (imaginemos un listado mal formateado.)
>¡El error no se podría reproducir!
>Reinicias el servidor y ¡ala! todo funciona (ahora todos
>los atributo titular son instancias de Cliente.)
>
>  
>
>>Incluso daría igual el cambiar una lista por un diccionario:
>>
>>   def __init__(self,coleccion):
>>     self.coleccion=coleccion
>>   def get(self,id_):
>>     return self.coleccion[id_]
>>    
>>
>
>pero el que usa el get debe saber que hay instancias a las
>que debe pasar un entero (las viejas, las que son listas)
>y otras (las nuevas, dict) a las que debe pasar un string
>o lo que el programador haya decidido usar como indice.
>
>No me parece razonable escribir codigo de mas que nunca
>se ejecutará luego del primer reinicio del sistema.
>
>  
>
>>Si está bien diseñado, bastaría con una actualización de los
>>atributos.
>>    
>>
>
>repito, mis objeciones no son sobre la programación en python.
>no creo que la forma de resolver el problema de las
>actualizaciones de versiones en caliente sea cambiando
>la clase de instancias en ejecucion.
>
>  
>
>>Más problemáticos son los cambios en las reglas de
>>negocio. Aún así se puede minimizar los problemas si se emplea un
>>buen diseño multicapa ("multi-tier"), de modo que los cambios en las
>>reglas de negocio no influyan tanto en el resto de la aplicación.
>>    
>>
>
>Esto ya es otra cosa.
>
>_______________________________________________
>Python-es mailing list
>Python-es en aditel.org
>http://listas.aditel.org/listinfo/python-es
>  
>