I'm have been trying to test this new audit function in trunk, but so far
the mything_archive table has never been created in any of my tests.
Is this the current state of the implementation, or am I missing something?
I downloaded the latest trunk and used it web2py admin to create a new app.
I then modified db.py according to the instructions in this thread:
....................................................
auth = Auth(db, hmac_key=Auth.get_or_create_key())
auth.define_tables(username=True, signature=True)
...
db.define_table("points",
Field('type','integer'),
Field('point','integer'),
Field('pointname','string'),
auth.signature)
auth.enable_record_versioning(db)
....................................................
I've tried this with both mysql and sqlite databases, but no *_archive
table...
Any comments or suggestions?
thanks, - Tom
On Thursday, April 5, 2012 4:16:04 PM UTC-6, Massimo Di Pierro 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?
>
>
>
>
>
>
>
On Thursday, April 5, 2012 4:16:04 PM UTC-6, Massimo Di Pierro 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?
>
>
>
>
>
>
>
