-
Sub-task
-
Resolution: Done
-
Major
-
None
-
None
-
None
-
13
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
3scale 2019-08-12, 3scale 2019-08-26, 3scale 2019-09-09, 3scale 2019-09-30, 3scale 2019-10-14, 3scale 2019-10-28, 3scale 2019-11-11, 3scale 2019-11-25, 3scale 2019-12-09
Testing in preview THREESCALE-2987, it may improve the efficiency of what we had before in production, and that's good for services, but it is not enough to enable again the deletion of tenants.
The most problematic queries to fix now are these 2:
-*************************** 21. row ***************************
Id: 30653
User: systemdb
Host: 10.128.226.31:15651
db: preview01
Command: Query
Time: 10
State: updating
Info: UPDATE `plans` SET `contracts_count` = COALESCE(`contracts_count`, 0) - 1 WHERE `plans`.`type` IN ('ApplicationPlan') AND `plans`.`id` = 957972
-
*************************** 11. row ***************************
Id: 30643
User: systemdb
Host: 10.128.226.31:15640
db: preview01
Command: Query
Time: 10
State: updating
Info: DELETE FROM `cms_templates` WHERE `cms_templates`.`provider_id` = 80 AND (`cms_templates`.`type` != 'CMS::LegalTerm')
I have checked the reason of the 1st one only, and it is that we have a 'contracts_count' for application_plans. I will explain with an example. Imagine that we have these objects and associations:
Tenant ID 2
-> Service ID 2
-> ApplicationPlan ID 2
-> Cinstance/Application ID 2 (For Developer ID 3)
-> Cinstance/Application ID 3 (For Developer ID 4)
-> Cinstance/Application ID 4 (For Developer ID 5)
-> ApplicationPlan ID 3
So for ApplicationPlan with ID 2 the field 'contracts_count' is 3, and it is there for the assumption that this field is read much more than updated so it is more efficient this way.
Then in the deletion in background what it currently happens is (imagine that we make the call to delete service ID 2 in background):
Destroy Cinstance/Application ID 2. Update ApplicationPlan ID 2 to have 'contracts_count' as '2' now. Destroy Cinstance/Application ID 3. Update ApplicationPlan ID 2 to have 'contracts_count' as '1' now. Destroy Cinstance/Application ID 4. Update ApplicationPlan ID 2 to have 'contracts_count' as '0' now. Destroy ApplicationPlan ID 2. Destroy ApplicationPlan ID 3. Destroy Service ID 2.
So this problematic query shouldn't be executed at all for this scenario because the plan is about to be destroyed as well anyway.
However, this execution in background must work no matter what is the object to be destroyed in background, so imagine that we make a call to destroy in background the Developer ID 3 only, and nothing else will be destroyed at all (the service will stay 
and the application plans will stay too we don't want to delete them in this example), then what happens right now is:
Destroy Cinstance/Application ID 2. Update ApplicationPlan ID 2 to have 'contracts_count' as '2' now. Destroy Developer ID 3.
And in this case the update makes sense because the plan will stay (and because it is updated only once!).
So it is hard to disable it only for this scenario, and Hery suggested the idea of not doing destroy and doing delete instead, and then making sure that we call all the callbacks by ourselves. But this is just an idea so far and needs to be thought in depth first.
The idea is something similar to what Gui did in https://github.com/3scale/porta/pull/944
There is also a deadlock in:
UPDATE plans SET position = (position - 1)
DONE
-*************************** 21. row ***************************
Id: 30653
User: systemdb
Host: 10.128.226.31:15651
db: preview01
Command: Query
Time: 10
State: updating
Info: UPDATE `plans` SET `contracts_count` = COALESCE(`contracts_count`, 0) - 1 WHERE `plans`.`type` IN ('ApplicationPlan') AND `plans`.`id` = 957972
- blocks
-
THREESCALE-2989 Enable the deletion of tenants
-
- Developing
-
- is blocked by
-
-
- Closed
-
