It appears to be fixed in trunk. I copied my entire app into a new directory. created a copy of the original db, data included. used appadmin to do fake migrates on all tables. commented out the enable_record_versioning in all model files. Turned off fake migrate. stopped and restarted the server (on my system rocket hangs after some kinds of model changes.) opened up appadmin on all affected applications - no errors. removed the comment to re-enable versioning again no problems with appadmin on affected apps.
Since I copied the database into a new db, the tables with names like attachments_archive_archive were still present. It did not create any tables with names like attachments_archive_archive_archive. So I call it fixed. On Friday, December 21, 2012 1:20:03 AM UTC-5, Massimo Di Pierro wrote: > > This helped me a lot understand the problem. I believe I have a fix in > trunk. Can you please check if the problem is indeed solved? > > On Thursday, December 20, 2012 1:21:21 PM UTC-6, Cliff Kachinske wrote: >> >> To enable archiving, I added enable_record_versioning(db) = True to my >> models files. >> >> I encountered the problems described in the two bug reports I submitted >> today on Google code. >> >> At one point I thought it would help with isolating the problem if I >> turned off versioning, so I commented out the line enabling it. >> >> When I uncommented the line, I found tables with names like >> "products_archive_archive." These are archive tables for the archive >> tables. >> >> I suppose if I repeated the sequence I would have tables with names like >> "products_archive_archive_archive." >> >> On Thursday, December 20, 2012 10:05:25 AM UTC-5, Massimo Di Pierro wrote: >>> >>> I do not understand. Can you explain? >>> >>> On Thursday, 20 December 2012 08:11:42 UTC-6, Cliff Kachinske wrote: >>>> >>>> I just discovered that auth.enable_record_versioning will create >>>> archive tables for the archive tables if turned off and turned back on. >>>> >>>> Not acceptable. >>>> >>> --
