Closed Bug 1332412 Opened 9 years ago Closed 6 years ago

don't fire onInsert/Update/Delete until after a transaction successfully commits

Categories

(Release Engineering Graveyard :: Applications: Balrog (backend), defect, P3)

defect

Tracking

(Not tracked)

RESOLVED MOVED

People

(Reporter: bhearsum, Assigned: njirap)

Details

(Whiteboard: [lang=python][ready])

We have callbacks that are meant to fire when changes are made to the database. Right now, they fire before the transaction is completed (eg: https://github.com/mozilla/balrog/blob/9f8de88056be59332faa9b79ba2517ad2b0caffa/auslib/db.py#L345), which means the callbacks may send e-mail or other notify changes that may end up failing to commit. I suspect the reason they ended up here is because we pass the query to them, so that interface may need to change.
Priority: -- → P3
Whiteboard: [lang=python][ready]
Assignee: nobody → ashish.sareen95
The bleeter method makes use of table, type of query, changed by , query and transaction as input parameters to initiate callbacks. Now, the transaction completely ends and commits when __exit__ method is invoked (eg: https://github.com/mozilla/balrog/blob/9f8de88056be59332faa9b79ba2517ad2b0caffa/auslib/admin/views/base.py#L61). So , if we'll have to write a new interface after the commit is successful, then : 1. What should be recorded in the new callbacks message? Same as the original (https://github.com/mozilla/balrog/blob/9f8de88056be59332faa9b79ba2517ad2b0caffa/auslib/db.py#L2082) or something else now ? 2. If same then need to pass the query and changed_by values up the stack after the validation and transaction has successfully completed. If I'm getting this right then the return values of all the APIs will need to return (Response, query, rest of input params) in return statement (eg: https://github.com/mozilla/balrog/blob/9f8de88056be59332faa9b79ba2517ad2b0caffa/auslib/admin/views/rules.py#L76) which will be first invoke callback then return response after this (eg: https://github.com/mozilla/balrog/blob/9f8de88056be59332faa9b79ba2517ad2b0caffa/auslib/admin/views/base.py#L61). ? What do you think ?
(In reply to Ashish Sareen from comment #1) > The bleeter method makes use of table, type of query, changed by , query and > transaction as input parameters to initiate callbacks. Now, the transaction > completely ends and commits when __exit__ method is invoked (eg: > https://github.com/mozilla/balrog/blob/ > 9f8de88056be59332faa9b79ba2517ad2b0caffa/auslib/admin/views/base.py#L61). So > , if we'll have to write a new interface after the commit is successful, > then : > 1. What should be recorded in the new callbacks message? Same as the > original > (https://github.com/mozilla/balrog/blob/ > 9f8de88056be59332faa9b79ba2517ad2b0caffa/auslib/db.py#L2082) or something > else now ? If possible, yes. At the very least, we need to know which objects are affected, and what changes have been made to them. > 2. If same then need to pass the query and changed_by values up the stack > after the validation and transaction has successfully completed. If I'm > getting this right then the return values of all the APIs will need to > return (Response, query, rest of input params) in return statement (eg: > https://github.com/mozilla/balrog/blob/ > 9f8de88056be59332faa9b79ba2517ad2b0caffa/auslib/admin/views/rules.py#L76) > which will be first invoke callback then return response after this (eg: > https://github.com/mozilla/balrog/blob/ > 9f8de88056be59332faa9b79ba2517ad2b0caffa/auslib/admin/views/base.py#L61). ? I think implementing this at the web layer is probably going to be tough, and may miss any cases where a call to the database layer ends up modifying multiple objects. To truly have this happen when the transaction commits, the best place is likely to be https://github.com/mozilla/balrog/blob/9f8de88056be59332faa9b79ba2517ad2b0caffa/auslib/db.py#L143. You may be able to iterate over parts of self.trans to get access to the information you need. I'm not 100% sure you'll be able to, but give it a shot.
Ashish, are you still planning to look at this?
Flags: needinfo?(ashish.sareen95)
Not at the moment. Still busy with gsoc project.
Flags: needinfo?(ashish.sareen95)
Assignee: ashish.sareen95 → nobody
Assignee: nobody → njirap
Apologies for the lack of progress here just seen it as a pending assigned bug. Working on it.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → MOVED
Product: Release Engineering → Release Engineering Graveyard
You need to log in before you can comment on or make changes to this bug.