© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
Here's my opinion on this... :-)
I understand your point on expanding [1] so that we could have something to hold onto for doing [2].
But when I started with this bug, my intention was the exact opposite and I've mentioned that in the comments & commit msg.
https:/
"""In this proposed solution, there are no foreign key based database
triggers/database scripts for the admin. Currently the segments are
released by the type driver loaded specific to that type. So this
change intends to use the type driver to release the segment."""
The reason for me not liking a db fix is explained below...
Note: These are just my thoughts, and please consider that I'm the least experienced in the group :-)
1) I don't see 'data in the DB' as the only potential dependency associated with a type driver. Imagine a type driver (may be from a vendor) which has to externally setup something (may be a device, or anything else which only it knows how to do) on creation, updation and also deletion. So those operations become very much type driver specific. IMHO the driver itself should delete the segment and that it the correct way.
2) Now when we've given an option for the admin to add/remove drivers using "type_drivers", what we've created is a monster not a mosquito! :-) It gives him all the power to configure that option anyway he wants, he can even decide to take drivers away for networks that are 'in operation', for whatever reasons (obsoleting, driver issues etc). This is the root cause of the issue.
Now to make him understand not to do that, and educate him to how to achieve the same with policies and all, is another point. But the reality is that there is an option for him to achieve that and it's quite easy to do
3) Rarity of occurrence may be a fact here. But IMO, when something like this happens it will be a big pain (https:/
If that is rare or not, I think that debate will never end :)
Even if that happens, my question is what's wrong with providing an option which is not otherwise used, and is empty by default. To be honest I really don't think this as over-engineering. Yeah my initial plan to detect the orphan types was a flawed over-engineering effort.
To summarise:
The fact that there is 'type_drivers' and it has the potential to create a mess as in (1) and (2) (although deemed rare) justify the provision of 'disabled_
[1] https:/
[2]shttps: