| 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 |