I am guessing that the new listener interface that would be called inside of transaction could also be used to ensure search indexing queue consistency.
The only concern that I have that the new interface would be misused to do more work inside transaction that would be strictly necessary. The documentation needs to be very clear here on what is allowed here. On 9 April 2013 23:12, Andrej Golcov <[email protected]> wrote: > Hi everyone, > > As a part of the investigation for ticket relation proposal [1], I > would like to discuss one issue with the community: how to make > changes in a new ticket relation mapping table consistently with > ticket modification - IMO, ticket relation changes should be a part of > the ticket modification transaction. > > How the problem is solved by other implementations: > - MasterTicketPlugin [2] listens for ITicketChangeListener events and > updates mapping table according to specific custom ticket field - this > approach brings potential problems with DB consistency, because > ITicketChangeListener events are called after the ticket transaction > was committed. > - TicketLinks [3] branch modifies the Trac Ticket code to update > mapping table during the ticket db transaction - this approach is not > convenient for us, because we want to be close to Trac main branch as > much as possible. > > My suggestion is to introduce a new interface > IResourceChangingListener that will be called before the main > transaction is committed and to put the ticket relation logics in a > Bloodhound specific plugin. I also hope that the interface could be > accepted by the Trac community, because it does not contain > ticket-relation specific code. Please consider the sample interface in > pastebin link: http://pastebin.com/BcH2AnS6 > > What do you think? Is it right direction to move? > > [1] https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0006 > [2] http://trac-hacks.org/wiki/MasterTicketsPlugin > [3] http://trac.edgewall.org/wiki/TicketLinks > > Cheers, Andrej >
