The problem is that the archive table includes a "current_record" field that references the original table, and because ondelete defaults to "CASCADE", when the original record is deleted, so are all the records that point to it.
It appears the current system is designed to store previous versions of records that still exist, not to archive records that no longer exist. If we want to enable archiving of deleted records, we would have to think about how it should work. In that case, all previous versions would have invalid references, so there would be no way to know they are related to each other. Probably the thing to do would be to archive the final version of the record and then change all previous versions to reference the archived final version. Maybe open a Google Code issue to request this feature. Anthony On Monday, February 17, 2014 5:20:49 PM UTC-5, Horst Horst wrote: > > I've just tried db.piece._enable_record_versioning(is_active = None), but > this gives me yet another behavior: Backup records appear in the archive > database on updates, but deleting records does not create backups but the > opposite: It deletes the record from the original table as well as all > backups referring to it. > > > Am Montag, 17. Februar 2014 14:02:36 UTC+1 schrieb Anthony: >> >> On Monday, February 17, 2014 7:24:24 AM UTC-5, Horst Horst wrote: >>> >>> I don't understand the rationale behind the way record versioning is >>> implemented: If you delete a record, it is marked as is_active=False in the >>> original table, but it is also copied to the my_table_archive table. >>> >>> Why this doubling of data? And /if/ data is doubled, why then not >>> immediately when records are inserted (into both, the regular table and the >>> archive), so that deletion could indeed delete from the original table? >>> >> >> As mentioned >> here<http://web2py.com/books/default/chapter/29/09/access-control#Record-versioning>, >> >> deletion is only prevented if the table in question includes an "is_active" >> field. So, if you don't include an "is_active" field, you will get a >> complete record deletion after the archiving. >> >> You can also prevent the is_active behavior by using the >> Table._enable_record_versioning method rather than >> auth.enable_record_versioning. The former takes an "is_active" argument, >> which is used to specify the name of the "is_active" field (in case you >> want to name it something else) -- if you pass in any falsey value for that >> argument, you don't get the is_active behavior (even if the table does in >> fact include an "is_active" field). >> >> This could probably be clarified in the book (particularly since record >> versioning is discussed in two different places). >> >> Anthony >> > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
