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

[Fernando Riquelme]

Podrías probar AuditLog (crea una tabla auditoria de acciones CRUD por cada
tabla), hace algo parecido a lo que dice Pedro, pero lo de Pedro está
buenísimo!

El 15 de junio de 2016, 7:11, Pedro Pezzarini <jose2190 en gmail.com> escribió:

> 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
>
>
> _______________________________________________
> 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/2289738b/attachment.html>