canmove, Confirmed users
1,570
edits
(→UI) |
|||
| Line 80: | Line 80: | ||
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. | 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. | ||
Note the local_strings table. This is used for the contributors, localizers and other multi-string localized metadata. The type column will be an enumeration of the different types. | |||
''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.'' | ''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.'' | ||