Extension Manager:Sqlite Storage: Difference between revisions

Jump to navigation Jump to search

Extension Manager:Sqlite Storage (view source)

Revision as of 11:08, 16 July 2008

435 bytes removed ,  16 July 2008
no edit summary
No edit summary
Line 50: Line 50:
=Proposed Changes=
=Proposed Changes=


Rather than being customised for displaying appropriately in the UI the database should instead be properly normalised with whatever information we need now and may need in the future. It should not include transient data that is only needed before the app restarts to keep the UI correct.
If we were to go the route of using sqlite templates to build the UI then it would be necessary to fill the database with all of the generated properties that are currently available on the EM rdf datasource as well as keep them up to date when things like the locale and preferences are changed in the application.


This means that information about add-ons waiting to be installed and downloaded will not be in the database. They instead should be held in in-memory data structures. It follows that the UI then will not be entirely generated by templates. Instead the Get Add-ons, Plugins, Updates and Installation panes will be programmatically handled. For the first two that should be relatively simple. The Updates and Installation panes will have to depend on notifications from the extension manager, much of which are already available on the install listener interface.
I don't believe that this is the sensible route to take. However instead it essentially requires that a new API be provided such that the UI can get the lists of installed add-ons and that contains methods to get those generated properties when necessary.


It is also likely not going to be possible to use templating for the extension lists. Firstly the sqlite templates do not respond to changes in the database, something which we could handle in a custom way for the add-ons manager but is unlikely to be implemented as standard. Secondly the large number of computed properties that the UI uses to display things correctly makes using a regular database query difficult. Many could potentially be handled with custom sqlite functions or custom code in the UI itself but I believe the best course of action is instead to effectively hide the database from the UI and use a proper API to get data on the add-ons, either extending or replacing nsIUpdateItem.
The database then should only contain the fixed information about installed add-ons, essentially all of the data read from the install.rdf, as well as any information needed to persist restarts like available update information.
 
This means that information about add-ons waiting to be installed and downloaded no longer need to be in the database. They can instead be held in in-memory data structures.


==Database Schema==
==Database Schema==


The database is made up of 6 tables:
The database will look roughly like this:


* addon (<u>addonid, installLocation</u>, version, ...., userDisabled)
[[Image:Extension_Manager-Sqlite_Storage-Schema.png]]
* targetApplication (<u>addonid, version, application</u>, maxVersion, minVersion)
* dependencies (<u>addonid, installLocation, requirement</u>, minVersion, maxVersion)
* localized (<u>addonid, installLocation, locale</u>, id)
* localizedData (<u>id</u>, name, ...)
* update (<u>addonid</u>, version, updateHash, updateURL)


There are some key points suggested in this design.
There are some key points suggested in this design.
Line 71: Line 68:
The addon table contains all known add-ons in all install locations. This is different from the current situation where we only cache data for the add-ons in the install location with the highest priority. This makes various future behaviours possible including using the newest version of an add-on regardless of installLocation, using any of the same add-on based on compatibility/blocklisting etc. We can create a view in the database that returns only the currently active add-ons for the common query cases.
The addon table contains all known add-ons in all install locations. This is different from the current situation where we only cache data for the add-ons in the install location with the highest priority. This makes various future behaviours possible including using the newest version of an add-on regardless of installLocation, using any of the same add-on based on compatibility/blocklisting etc. We can create a view in the database that returns only the currently active add-ons for the common query cases.


The targetApplication table is keyed on addonid and version rather than being a foreign key into the addon table. It should keep targetApplication information for all installLocations, since an add-on might be installed with the same version in different installLocations there is no need to duplicate that information in the database. Likewise known updates have their targetApplication info here. We could potentially think about caching this information almost permanently such that future installs of a previously installed add-on may not need another compatibility update check.
The target_application table is linked to add-ons by addon id and version rather than being a foreign key into the addon table. Since an add-on might be installed with the same version in different installLocations there is no need to duplicate the compatibility information (which should be the same) in the database. Likewise known updates have their targetApplication info here. We could potentially think about caching this information almost permanently such that future installs of a previously installed add-on may not need another compatibility update check.


''Might want to do the same for the dependencies, however right now they come only out of the install.rdf and are never updated by remote data.''
''Might want to do the same for the requirements, however right now they come only out of the install.rdf and are never updated by remote data.''


''Still need to consider what generated properties should be held in the database. We could go with just appDisabled as currently, or we could store blocklisted, compatible and updatesSecurely separately.''
''Do we actually need to keep all the targetApplication data? We do currently but all we need for compatibility checks is minVersion and maxVersion and the app (toolkit/firefox). I'm generally in favour of keeping as much data but querying compatibility would be much simpler with the min/maxversion in the addon table''


''Do we actually need to keep all the targetApplication data? We do currently but all we need for compatibility checks is minVersion and maxVersion and the app (toolkit/firefox). I'm generally in favour of keeping as much data but querying compatibility would be much simpler with the min/maxversion in the addon table''
==UI==
 
Currently the UI is purely template based which has meant that plugin and add-on search results have ended up being put into in-memory rdf datasources. Switching away from templates will allow us to break this into a more straightforward approach. We just have one richlistbox per pane in a deck, on startup we create richlistitems for every installed add-on, plugin and search results when available.
 
For the install and add-on lists we will have to have some kind of notification from the EM backend to the UI to let it know that a change has been made that might require updating the UI. Add-on properties don't change all that much, mainly state changes which should make this easy to handle.


==API==
==API==
Mossop
canmove, Confirmed users
1,570

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/100633"

Navigation menu