Bug #324
Old Source Variables Left Behind
| Status: | Closed | Start: | 08/11/2010 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assigned to: | mykroft | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - |
Description
While working on a source plugin, if a variable name is changed, and the plugin is ran and apply it clicked, the module saves the new variables with current/new names in the sql database, the OLD variable names are left behind orphaned.
My suggestion is upon a <Apply> for a source module update, the main module/function that saves the config - should delete all vars entries in the database for that source module before inserting/updating the current names/values. This way orphans will not get left behind and clutter up the database
History
Updated by tshif almost 2 years ago
- Status changed from New to Reviewed
- Assigned to set to mykroft
This makes sence to me. I suggest you write it into the new version of XBMC you are working on as a trial balloon. If it works well, we should export the idea to all the data sources that have configuration items associated with them.
Updated by mykroft almost 2 years ago
tshif wrote:
This makes sence to me. I suggest you write it into the new version of XBMC you are working on as a trial balloon. If it works well, we should export the idea to all the data sources that have configuration items associated with them.
the source- module(s) dont have anything to do with saving/loading the config - it would be in the main freepbx module itself. I will start hunting for it and report back
Updated by tshif almost 2 years ago
I think it should be doable from the data source - Im not sure I want to approach that change in the main code for the upcomming maintenance release. By all means investigate if you wish - but for now I wouldnt spend to much time on it.
This issue does not block the release of the upgraded XBMC data source.
Updated by mykroft almost 2 years ago
tshif wrote:
I think it should be doable from the data source - Im not sure I want to approach that change in the main code for the upcomming maintenance release. By all means investigate if you wish - but for now I wouldnt spend to much time on it.
This issue does not block the release of the upgraded XBMC data source.
The issue will not block any source module update/release - it just leaves behind a dirty database..
Updated by mykroft almost 2 years ago
- Status changed from Reviewed to Closed
Updated by tshif over 1 year ago
- Target version deleted (
Caller ID Superfecta - Future Versions)