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)
Release Engineering Graveyard
Applications: Balrog (backend)
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.
| Reporter | ||
Updated•9 years ago
|
Priority: -- → P3
Whiteboard: [lang=python][ready]
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 ?
| Reporter | ||
Comment 2•9 years ago
|
||
(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.
| Reporter | ||
Comment 3•8 years ago
|
||
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)
Apologies for the lack of progress here just seen it as a pending assigned bug. Working on it.
| Reporter | ||
Comment 6•6 years ago
|
||
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → MOVED
Updated•6 years ago
|
Product: Release Engineering → Release Engineering Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•