Hi, I tried using your new versioning feature in trunk. I created an app using a mysql database: db = DAL('mysql://version:version@localhost/version') When I used the admin function to define a new user I received the following error: ........................................ <class 'gluon.contrib.pymysql.err.IntegrityError'> (1452, u'Cannot add or update a child row: a foreign key constraint fails (`version/auth_user`, CONSTRAINT `auth_user_ibfk_1` FOREIGN KEY (`created_by`) REFERENCES `auth_user` (`id`) ON DELETE CASCADE)') ........................................
I rebuilt the app to use sqlite instead of mysql: db = DAL('sqlite://storage.sqlite') I was then able to add a user without the error I was using MySQL client version: 5.0.84 - any suggestions? - 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? > > > > > > >