[pyar] South se confunde cuando le cambio el nombre a una property?
Federico Heinz
fheinz en vialibre.org.ar
Jue Sep 9 12:32:01 ART 2010
On 09/09/2010, Anthony Lenton wrote:
> No modifica la DB, pero sí la "serialización" de tus modelos que usa
> South -- ese diccionario grandote que pone al final de cada
> migración, fijate que antes tenías un "bar", y después de la
> migración debés tener un "_bar".
Sí, por eso se me ocurrió que podía funcionar lo de modificar la
migración generada. De todos modos, me parece que es un bug de South:
la decisión de si cambió algo o no debería estar basada en si
cambiaron atributos de la base de datos, no de su representación en
objetos Python. Ya lo reporto.
> Por otro lado, lo de usar properties para wrappear tus atributos
> para que tengan otros side effects me hace un poco de ruido... no
> podrías redefinir save, y meter tus efectos secundarios ahí en vez?
No es un side effect: es parte del comportamiento del objeto.
Podría redefinir save(), o podría usar la señal de save... pero
estrictamente, es una chanchada. Semánticamente, lo que quiero es
que se produzca ese comportamiento, desde el punto de vista de diseño
orientado a objetos *lo que corresponde* es wrappear el atributo. Las
otras maneras podrían lograr parte del objetivo, pero no es
exactamente lo que quiero:
* hay un tiempo entre que asigno un valor a f.bar y se ejecuta
save() en el que el objeto está en un estado potencialmente
inconsistente,
* no quiero que se ejecute *todas las veces que se guarda el
objeto*, sino sólo aquellas en las que f.bar obtiene un nuevo
valor. De hecho, ejecutarlo en cada save() produce resultados
incorrectos.
Estaba pensando que la forma más pythónica de resolver esto sería que
los ModelFields aceptaran un parámetro "property", cosa de poder hacer
class Foo(models.Model):
_bar = models.ForeignKey('Bar', db_column='bar_id',
property='bar')
Pero me fijé y no encontré nada parecido en la documentación.
Fede
More information about the pyar
mailing list