Massimo, this is great!
Question: does it keep a copy of the latest previous record only (I'm
sorry, I hope that made sense), or do all submitted changes get copied to
archive (a new record is stored for each submitted change) ?
If the answer is "all submitted changes get copied" , then I would like to
follow up with comments and questions (I'll try to keep them short, promise
;) ).
I'm about to pull trunk in a few minutes and try this feature.
Thanks,
Mart :)
On Thursday, April 5, 2012 7:11:26 PM UTC-4, Massimo Di Pierro wrote:
>
> Now you can. ;-)
>
> auth.enable_record_versioning(db, archive_db=other_db)
>
>
> On Thursday, 5 April 2012 17:28:43 UTC-5, rochacbruno wrote:
>>
>> is it possible to redirect the archive to a separate database?
>>
>> On Thu, Apr 5, 2012 at 7:16 PM, Massimo Di Pierro <
>> massimo.dipie...@gmail.com> wrote:
>>
>>> This is how it works:
>>>
>>> # define auth
>>> auth = Auth(db, hmac_key=Auth.get_or_create_key())
>>> auth.define_tables(username=True,signature=True)
>>>
>>> # define your own tables like
>>> db.define_table('mything',Field('name'),auth.signature)
>>>
>>> # than do:
>>> auth.enable_record_versioning(db)
>>>
>>> how does it work? every table, including auth_user will have an
>>> auth.signature including created_by, created_on, modified_by, modified_on,
>>> is_active fields. When a record of table mything (or any other table) is
>>> modified, a copy of the previous record is copied into mything_archive
>>> which references the current record. When a record is deleted, it is not
>>> actually deleted but is_active is set to False, all records with
>>> is_active==False are filtered out in searches except in appadmin.
>>>
>>> Pros:
>>> - your app will get full record archival for auditing purposes
>>> - could not be simpler. nothing else to do. Try with
>>> SQLFORM.grid(db.mything) for example.
>>> - does not break references and there is no need for uuids
>>> - does not slow down searches because archive is done in separate
>>> archive tables
>>>
>>> Cons:
>>> - uses lots of extra memory because every version of a record is stored
>>> (it would be more efficient to store changes only but that would make more
>>> difficult to do auditing).
>>> - slows down db(...).update(...) for multi record because it needs to
>>> copy all records needing update from the original table to the archive
>>> table. This requires selecting all the records.
>>>
>>> Comments? Suggestions?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>>
>> Bruno Rocha
>> [http://rochacbruno.com.br]
>>
>>
