From: Nick H. <nic...@ho...> - 2011-02-21 19:49:07
|
Benny Malengier wrote: > > > 2011/2/21 Nick Hall <nic...@ho... > <mailto:nic...@ho...>> > > Michiel, > > When I was updating the tagging code, I noticed that the object-delete > signals are still issued after the object has been deleted. > > The tagging code tries to get the deleted tag from the handle, which > causes a problem. I can get around this, but it could cause a problem > elsewhere. > > Should I modify the tagging code to cope with this change, or > should we > issue the object-delete signal before the object is removed from the > database? > > > No, you should change your code. > If you need data from objects after deletion (other than the passed > handle), you should cache that info. > The reason I agreed with this change of Michael is that deleting can > take a long time if we wait for end of signal before doing the delete. > This is problematic, as the window for a crash, and hence an abort of > the transaction, increases dramatically like this. Doing delete signal > after the actual delete means we don't loose the transaction if the > code reacting to the signal crashes. > You see this in gen/db/write.py, transaction_commit method does the > self.bsddbtxn.commit() code and then signals are triggered, so crash > of those no longer undoes the bsddb change. I just wanted to check that this change was intentional. I have committed some updated tagging code (r16690). > > Another reason is that a rebuild signal also happens after a batch > transaction, so your code should already be able to handle that. Yes, I already handle the rebuild signal, but I re-read the whole table when I receive this. As the tags table is likely to be small, I suppose I could save a few lines of code by doing a rebuild for all changes, but it is not necessary. There are a couple of issues that I noticed when testing the tagging code. 1. When a transaction is aborted it still appears in the undo history. 2. Long transactions cause unwanted effects in the listviews. This is because the model changes when the database is updated, but the signals can take some time to arrive. Nick. > > Benny > > > > > Nick. > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel > Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > <mailto:Gra...@li...> > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |