Name Description Size
CalStorageCachedItemModel.sys.mjs CalStorageCachedItemModel extends CalStorageItemModel to add caching support for items. Most of the methods here are overridden from the parent class to either add or retrieve items from the cache. 6660
CalStorageCalendar.sys.mjs Initialize the Database. This should generally only be called from the uri or id setter and requires those two attributes to be set. It may also be called again when the schema version of the database is newer than the version expected by this version of Thunderbird. 17451
CalStorageDatabase.sys.mjs Checks for an existing SQLite connection to `file`, or creates a new one. Calls to `openConnectionTo` and `closeConnection` are counted so we know if a connection is no longer used. @param {nsIFile} file @returns {mozIStorageConnection} 9320
calStorageHelpers.sys.mjs Transforms the text representation of this date object to a calIDateTime object. @param text The text to transform. @returns The resulting calIDateTime. 3664
CalStorageItemModel.sys.mjs CalStorageItemModel provides methods for manipulating item data. 47736
CalStorageMetaDataModel.sys.mjs CalStorageMetaDataModel provides methods for manipulating the metadata stored on items. 2537
CalStorageModelBase.sys.mjs CalStorageModelBase is the parent class for the storage calendar models. The idea here is to leave most of the adjustments and integrity checks to CalStorageCalendar (or other classes) while focusing mostly on retrieval/persistence in the children of this class. 1815
CalStorageModelFactory.sys.mjs CalStorageModelFactory provides a convenience method for creating instances of the storage calendar models. Use to avoid having to import each one directly. 1741
CalStorageOfflineModel.sys.mjs CalStorageOfflineModel provides methods for manipulating the offline flags of items. 1561
CalStorageStatements.sys.mjs CalStorageStatements contains the mozIStorageBaseStatements used by the various storage calendar models. Remember to call the finalize() method when shutting down the db. 22714
calStorageUpgrade.sys.mjs Welcome to the storage database migration. If you would like to change anything in the database schema, you must follow some steps to make sure that upgrading from old versions works fine. First of all you must increment the DB_SCHEMA_VERSION variable below. Then you must write your upgrader. To do this, create a new function and add it to the upgrade object, similar to the existing upgraders below. An example is given below. An upgrader MUST update both the database (if it is passed) AND the table data javascript object. An example for a such object is in the v1/v2 upgrader. The process of upgrading calls the latest upgrader with the database object and the current database version. The whole chain of upgraders is then called (down to v1). The first upgrader (v1/v2) provides the basic table data object. Each further upgrader then updates this object to correspond with the database tables and columns. No actual database calls are made until the first upgrader with a higher version than the current database version is called. When this version is arrived, both the table data object and the database are updated. This process continues until the database is at the latest version. Note that your upgrader is not necessarily called with a database object, for example if the user's database is already at a higher version. In this case your upgrader is called to compile the table data object. To make calling code easier, there are a bunch of helper functions below that can be called with a null database object and only call the database object if it is not null. If you need to call new functions on the database object, check out the createDBDelegate function below. When adding new tables to the table data object, please note that there is a special prefix for indexes. These are also kept in the table data object to make sure that getAllSql also includes CREATE INDEX statements. New tables MUST NOT be prefixed with "idx_". If you would like to add a new index, please use the createIndex function. The basic structure for an upgrader is (NN is current version, XX = NN - 1) upgrader.vNN = function upgrade_vNN(db, version) { let tbl = upgrade.vXX(version < XX && db, version); LOGdb(db, "Storage: Upgrading to vNN"); beginTransaction(db); try { // Do stuff here setDbVersionAndCommit(db, NN); } catch (e) { throw reportErrorAndRollback(db, e); } return tbl; } Regardless of how your upgrader looks, make sure you: - use an sql transaction, if you have a database - If everything succeeds, call setDbVersionAndCommit to update the database version (setDbVersionAndCommit also commits the transaction) - If something fails, throw reportErrorAndRollback(db, e) to report the failure and roll back the transaction. If this documentation isn't sufficient to make upgrading understandable, please file a bug. 60081
components.conf 541
moz.build 808