[pyar] [Django] Best practice en diseño de modelos

[Pedro Pezzarini]

Hola Rafael, te comento el caso de uno de nuestros clientes que tiene un
sistema médico que hicimos con django y postgres.

Nosotros hacemos un dump en json del modelo (al estilo reversion) y lo
tiramos a un Mongo, entonces por un lado tenés los datos y por otro un
historial de lo borrado (entre otras cosas como usuario, fecha hora, bucket
etc)

No se si sera muy canónico pero funciona bien .

Saludos!

El mié., jun. 15, 2016 1:14 AM, Leonardo Lazzaro <lazzaroleonardo en gmail.com>
escribió:

> Hola,
>
> Para tu problema del borrado fijate de ver estas apps:
>
>    - django-safedelete <https://github.com/makinacorpus/django-safedelete> :
>    En la doc
>    <https://django-safedelete.readthedocs.io/en/latest/models.html#policies>
>    dice que si usas la policy SOFT_DELETE tiene el comportamiento que esperas.
>    - Despues por otro lado tenes django-reversion
>    <https://github.com/etianen/django-reversion> pero quiza es para otro
>    caso de uso. fijate que te "vende" el feature "Roll back to any point in a
>    model instance’s history."
>
> Espero que sirva!
> Leonardo
>
> El 14 de junio de 2016, 20:30, Rafael E. Ferrero <rafael.ferrero en gmail.com
> > escribió:
>
>> Gente, buenas tardes !!
>>
>> Introduccion:
>> En un proyecto Django creemos conveniente, en muchas clases pero no
>> todas, NO borrar definitivamente los registros de una base de datos sino
>> marcarlos como borrados, cosa que si se quiere recuperar se recupera
>> solamente borrando la marca. Obviamente esto podría generar un incremento
>> innecesario de la base de datos por lo que despues de cierto tiempo en ese
>> estado los marcariamos tambien como historico y con un proceso cada Y
>> periodo de tiempo depurariamos la base de datos y todos estos registros
>> historicos irían a parar a un backup.
>>
>> ¿Alguien se topo con un requerimiento similar en algún momento? ¿Cómo lo
>> resolvieron?
>>
>> o sino ¿Qué consideran sea una buena práctica para encarar esto?
>>
>> Por el momento a cada clase (del models.py) que creemos que es importante
>> no perder tan facilmente le cree los campos boolean Borrado e Historico,
>> usuario que creo el registro y fecha de creacion, usuario de la ultima
>> modificacion y su fecha de modificacion... y pensaba en cambiar la accion
>> de borrado de django por la de marcar el campo "Borrado" y tomar la fecha
>> de borrado.... el tema es que esto es en varias clases... ¿sería mejor si
>> hago una clase base abstracta con estos campos y que las clases que
>> necesite de estos campos hereden de ella? Si una clase necesita heredar de
>> esta y también necesite heredar de otra ¿Está bien visto la herencia
>> múltiple en estos casos o estoy metiendo un nivel de complejidad al dope?
>>
>> Fue largo, lo sé por eso gracias de ante mano a los que se tomaron el
>> tiempo de llegar hasta esta línea.
>>
>> Saludos !!
>>
>> Rafael E. Ferrero
>>
>> _______________________________________________
>> pyar mailing list pyar en python.org.ar
>> http://listas.python.org.ar/listinfo/pyar
>>
>> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>>
>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>> Argentina - http://www.usla.org.ar
>>
>
>
>
> --
> https://github.com/llazzaro
>
> gpg/pgp key: 0x45e1ecde06521134
> <http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x45e1ecde06521134>
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20160615/cacca7bb/attachment-0001.html>