Re: [Gramps-devel] Transaction changes and delete signals

[Benny M. <ben...@gm...>]

2011/2/21 Nick Hall <nic...@ho...>

>
>
> 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.
>

Post a bug for this.

>
> 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.
>

Hmm, I thought the model only updates on the signals. So you mean code that
fetches from database while the data is no longer present so as to fill
rows? Any specific use-case? I was hoping the cache in the listviews would
handle this sufficiently (so only hitting the model, not the changed
database).

Benny