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

Leonardo Lazzaro lazzaroleonardo en gmail.com
Mie Jun 15 01:12:57 ART 2016


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>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20160615/128a6ba1/attachment.html>


Más información sobre la lista de distribución pyar