Fixed in trunk.

On Saturday, 14 April 2012 23:10:18 UTC-5, tomt wrote:
>
> I discovered why the archive table wasn't being created, there is a typo 
> in gluon/tools.py at line 1293:
>         for table in tables: 
>             if 'modifed_on' in table.fields():
> should be
>         for table in tables: 
>             if 'modified_on' in table.fields():
>
> Now the the 'mythings_archive' table is created as expected, and changes 
> are recorded in it as expected.
>
> I didn't mention it before, but I expect that the builtin audit feature 
> will be very useful for my applications.  This feature along with the 
> addition of SQLFORM.grid have made web2py enormously more productive.
>
> Thanks to all the developers for all these improvements.
> - Tom
>
>
>
> On Friday, April 13, 2012 10:53:10 PM UTC-6, tomt wrote:
>>
>> 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?
>>>
>>>
>>>
>>>
>>>
>>>
>>>

Reply via email to