Name Description Size
build 3
FileSystemModule.cpp 7102
FileSystemModule.h 652
IStorageBindingParamsInternal.h Implementation-only interface for mozIStorageBindingParams. This defines the set of methods required by the asynchronous execution code in order to consume the contents stored in mozIStorageBindingParams instances. 1872
moz.build 2990
mozIStorageAsyncConnection.idl mozIStorageAsyncConnection represents an asynchronous database connection attached to a specific file or to an in-memory data storage. It is the primary interface for interacting with a database from the main thread, including creating prepared statements, executing SQL, and examining database errors. 12738
mozIStorageAsyncStatement.idl An asynchronous SQL statement. This differs from mozIStorageStatement by only being usable for asynchronous execution. (mozIStorageStatement can be used for both synchronous and asynchronous purposes.) This specialization for asynchronous operation allows us to avoid needing to acquire synchronization primitives also used by the asynchronous execution thread. In contrast, mozIStorageStatement may need to acquire the primitives and consequently can cause the main thread to lock for extended intervals while the asynchronous thread performs some long-running operation. 1595
mozIStorageBaseStatement.idl The base interface for both pure asynchronous storage statements (mozIStorageAsyncStatement) and 'classic' storage statements (mozIStorageStatement) that can be used for both synchronous and asynchronous purposes. 4799
mozIStorageBindingParams.idl Binds aValue to the parameter with the name aName. @param aName The name of the parameter to bind aValue to. @param aValue The value to bind. 4658
mozIStorageBindingParamsArray.idl Creates a new mozIStorageBindingParams object that can be added to this array. @return a mozIStorageBindingParams object that can be used to specify parameters that need to be bound. 1089
mozIStorageCompletionCallback.idl Indicates that the event this callback was passed in for has completed. @param status The status of the call. Generally NS_OK if the operation completed successfully. @param value If the operation produces a result, the result. Otherwise, |null|. @see The calling method for expected values. 932
mozIStorageConnection.idl mozIStorageConnection represents a database connection attached to a specific file or to the in-memory data storage. It is the primary interface for interacting with a database, including creating prepared statements, executing SQL, and examining database errors. @note From the main thread, you should rather use mozIStorageAsyncConnection. @threadsafe 9704
mozIStorageError.idl General SQL error or missing database. 2621
mozIStorageFunction.idl mozIStorageFunction is to be implemented by storage consumers that wish to receive callbacks during the request execution. SQL can apply functions to values from tables. Examples of such functions are MIN(a1,a2) or SQRT(num). Many functions are implemented in SQL engine. This interface allows consumers to implement their own, problem-specific functions. These functions can be called from triggers, too. 1346
mozIStoragePendingStatement.idl Cancels a pending statement, if possible. This will only fail if you try cancel more than once. @note For read statements (such as SELECT), you will no longer receive any notifications about results once cancel is called. 744
mozIStorageProgressHandler.idl mozIProgressHandler is to be implemented by storage consumers that wish to receive callbacks during the request execution. 913
mozIStorageResultSet.idl Obtains the next row from the result set from the statement that was executed. @returns the next row from the result set. This will be null when there are no more results. 729
mozIStorageRow.idl Obtains the result of a given column specified by aIndex. @param aIndex Zero-based index of the result to get from the tuple. @returns the result of the specified column. 1238
mozIStorageService.idl The mozIStorageService interface is intended to be implemented by a service that can create storage connections (mozIStorageConnection) to either a well-known profile database or to a specific database file. This is the only way to open a database connection. @note The first reference to mozIStorageService must be made on the main thread. 9001
mozIStorageStatement.idl A SQL statement that can be used for both synchronous and asynchronous purposes. 10196
mozIStorageStatementCallback.idl Called when some result is obtained from the database. This function can be called more than once with a different storageIResultSet each time for any given asynchronous statement. @param aResultSet The result set containing the data from the database. 1791
mozIStorageVacuumParticipant.idl This interface contains the information that the Storage service needs to vacuum a database. This interface is created as a service through the category manager with the category "vacuum-participant". Please see https://developer.mozilla.org/en/mozIStorageVacuumParticipant for more information. 2282
mozIStorageValueArray.idl mozIStorageValueArray wraps an array of SQL values, such as a single database row. 5270
mozStorageArgValueArray.cpp 5050
mozStorageArgValueArray.h 870
mozStorageAsyncStatement.cpp 11173
mozStorageAsyncStatement.h Initializes the object on aDBConnection by preparing the SQL statement given by aSQLStatement. @param aDBConnection The Connection object this statement is associated with. @param aNativeConnection The native Sqlite connection this statement is associated with. @param aSQLStatement The SQL statement to prepare that this object will represent. 2929
mozStorageAsyncStatementExecution.cpp The following constants help batch rows into result sets. MAX_MILLISECONDS_BETWEEN_RESULTS was chosen because any user-based task that takes less than 200 milliseconds is considered to feel instantaneous to end users. MAX_ROWS_PER_RESULT was arbitrarily chosen to reduce the number of dispatches to calling thread, while also providing reasonably-sized sets of data for consumers. Both of these constants are used because we assume that consumers are trying to avoid blocking their execution thread for long periods of time, and dispatching many small events to the calling thread will end up blocking it. 19713
mozStorageAsyncStatementExecution.h Describes the state of execution. 7816
mozStorageAsyncStatementJSHelper.cpp 4683
mozStorageAsyncStatementJSHelper.h A modified version of StatementJSHelper that only exposes the async-specific 'params' helper. We do not expose 'row' or 'step' as they do not apply to us. 1629
mozStorageAsyncStatementParams.cpp 3883
mozStorageAsyncStatementParams.h 2302
mozStorageBindingParams.cpp 14297
mozStorageBindingParams.h Locks the parameters and prevents further modification to it (such as binding more elements to it). 3758
mozStorageBindingParamsArray.cpp 2241
mozStorageBindingParamsArray.h Locks the array and prevents further modification to it (such as adding more elements to it). 2759
mozStorageConnection.cpp Nothing 77145
mozStorageConnection.h Indicates if a database operation is synchronous or asynchronous. - Async operations may be called from any thread for all connections. - Sync operations may be called from any thread for sync connections, and from background threads for async connections. 17477
mozStorageError.cpp Note: This object is only ever accessed on one thread at a time. It it not threadsafe, but it does need threadsafe AddRef and Release. 1130
mozStorageError.h 809
mozStorageHelper.h This class wraps a transaction inside a given C++ scope, guaranteeing that the transaction will be completed even if you have an exception or return early. A common use is to create an instance with aCommitOnComplete = false (rollback), then call Commit() on this object manually when your function completes successfully. @note nested transactions are not supported by Sqlite, only nested savepoints, so if a transaction is already in progress, this object creates a nested savepoint to the existing transaction which is considered as anonymous savepoint itself. However, aType and aAsyncCommit are ignored in the case of nested savepoints. @param aConnection The connection to create the transaction on. @param aCommitOnComplete Controls whether the transaction is committed or rolled back when this object goes out of scope. @param aType [optional] The transaction type, as defined in mozIStorageConnection. Uses the default transaction behavior for the connection if unspecified. @param aAsyncCommit [optional] Whether commit should be executed asynchronously on the helper thread. This is a special option introduced as an interim solution to reduce main-thread fsyncs in Places. Can only be used on main-thread. WARNING: YOU SHOULD _NOT_ WRITE NEW MAIN-THREAD CODE USING THIS! Notice that async commit might cause synchronous statements to fail with SQLITE_BUSY. A possible mitigation strategy is to use PRAGMA busy_timeout, but notice that might cause main-thread jank. Finally, if the database is using WAL journaling mode, other connections won't see the changes done in async committed transactions until commit is complete. For all of the above reasons, this should only be used as an interim solution and avoided completely if possible. 11288
mozStoragePrivateHelpers.cpp 7672
mozStoragePrivateHelpers.h This file contains convenience methods for mozStorage. 4668
mozStorageResultSet.cpp Note: This object is only ever accessed on one thread at a time. It it not threadsafe, but it does need threadsafe AddRef and Release. 1359
mozStorageResultSet.h Adds a tuple to this result set. 1172
mozStorageRow.cpp Note: This object is only ever accessed on one thread at a time. It it not threadsafe, but it does need threadsafe AddRef and Release. 5990
mozStorageRow.h Initializes the object with the given statement. Copies the values from the statement. @param aStatement The sqlite statement to pull results from. 1344
mozStorageService.cpp Passes a single SQLite memory statistic to a memory reporter callback. @param aHandleReport The callback. @param aData The data for the callback. @param aConn The SQLite connection. @param aPathHead Head of the path for the memory report. @param aKind The memory report statistic kind, one of "stmt", "cache" or "schema". @param aDesc The memory report description. @param aOption The SQLite constant for getting the measurement. @param aTotal The accumulator for the measurement. 24930
mozStorageService.h Initializes the service. This must be called before any other function! 5437
mozStorageSQLFunctions.cpp Performs the LIKE comparison of a string against a pattern. For more detail see http://www.sqlite.org/lang_expr.html#like. @param aPatternItr An iterator at the start of the pattern to check for. @param aPatternEnd An iterator at the end of the pattern to check for. @param aStringItr An iterator at the start of the string to check for the pattern. @param aStringEnd An iterator at the end of the string to check for the pattern. @param aEscapeChar The character to use for escaping symbols in the pattern. @return 1 if the pattern is found, 0 otherwise. 12691
mozStorageSQLFunctions.h Registers the functions declared here with the specified database. @param aDB The database we'll be registering the functions with. @return the SQLite status code indicating success or failure. 2859
mozStorageStatement.cpp 26047
mozStorageStatement.h Initializes the object on aDBConnection by preparing the SQL statement given by aSQLStatement. @param aDBConnection The Connection object this statement is associated with. @param aNativeConnection The native Sqlite connection this statement is associated with. @param aSQLStatement The SQL statement to prepare that this object will represent. 3997
mozStorageStatementData.h Return the sqlite statement, fetching it from the storage statement. In the case of AsyncStatements this may actually create the statement 4704
mozStorageStatementJSHelper.cpp 7888
mozStorageStatementJSHelper.h Wrappers used to clean up the references JS helpers hold to the statement. For cycle-avoidance reasons they do not hold reference-counted references, so it is important we do this. 1725
mozStorageStatementParams.cpp 4098
mozStorageStatementParams.h MOZSTORAGESTATEMENTPARAMS_H 1997
mozStorageStatementRow.cpp 4515
mozStorageStatementRow.h MOZSTORAGESTATEMENTROW_H 1449
ObfuscatingVFS.cpp 2020-04-20 * * The author disclaims copyright to this source code. In place of * a legal notice, here is a blessing: * * May you do good and not evil. * May you find forgiveness for yourself and forgive others. * May you share freely, never taking more than you give. * ***************************************************************************** * * This file implements a VFS shim that obfuscates database content * written to disk by applying a CipherStrategy. * * COMPILING * * This extension requires SQLite 3.32.0 or later. * * * LOADING * * Initialize it using a single API call as follows: * * sqlite3_obfsvfs_init(); * * Obfsvfs is a VFS Shim. When loaded, "obfsvfs" becomes the new * default VFS and it uses the prior default VFS as the next VFS * down in the stack. This is normally what you want. However, it * complex situations where multiple VFS shims are being loaded, * it might be important to ensure that obfsvfs is loaded in the * correct order so that it sequences itself into the default VFS * Shim stack in the right order. * * USING * * Open database connections using the sqlite3_open_v2() with * the SQLITE_OPEN_URI flag and using a URI filename that includes * the query parameter "key=XXXXXXXXXXX..." where the XXXX... consists * of 64 hexadecimal digits (32 bytes of content). * * Create a new encrypted database by opening a file that does not * yet exist using the key= query parameter. * * LIMITATIONS: * * * An obfuscated database must be created as such. There is * no way to convert an existing database file into an * obfuscated database file other than to run ".dump" on the * older database and reimport the SQL text into a new * obfuscated database. * * * There is no way to change the key value, other than to * ".dump" and restore the database * * * The database page size must be exactly 8192 bytes. No other * database page sizes are currently supported. * * * Memory-mapped I/O does not work for obfuscated databases. * If you think about it, memory-mapped I/O doesn't make any * sense for obfuscated databases since you have to make a * copy of the content to deobfuscate anyhow - you might as * well use normal read()/write(). * * * Only the main database, the rollback journal, and WAL file * are obfuscated. Other temporary files used for things like * SAVEPOINTs or as part of a large external sort remain * unobfuscated. * * * Requires SQLite 3.32.0 or later. 23977
rust 2
SQLCollations.cpp Helper function for the UTF-8 locale collations. @param aService The Service that owns the collator used by this collation. @param aLen1 The number of bytes in aStr1. @param aStr1 The string to be compared against aStr2 as provided by SQLite. It must be a non-null-terminated char* buffer. @param aLen2 The number of bytes in aStr2. @param aStr2 The string to be compared against aStr1 as provided by SQLite. It must be a non-null-terminated char* buffer. @param aSensitivity The sorting sensitivity. @return aStr1 - aStr2. That is, if aStr1 < aStr2, returns a negative number. If aStr1 > aStr2, returns a positive number. If aStr1 == aStr2, returns 0. 7548
SQLCollations.h Registers the collating sequences declared here with the specified database and Service. @param aDB The database we'll be registering the collations with. @param aService The Service that owns the collator used by our collations. @return the SQLite status code indicating success or failure. 9447
SQLiteMutex.h Wrapper class for sqlite3_mutexes. To be used whenever we want to use a sqlite3_mutex. @warning Never EVER wrap the same sqlite3_mutex with a different SQLiteMutex. If you do this, you void the deadlock detector's warranty! 3886
StatementCache.h Class used to cache statements (mozIStorageStatement or mozIStorageAsyncStatement). 3901
storage.h 840
StorageBaseStatementInternal.cpp Used to finalize an asynchronous statement on the background thread. 7967
StorageBaseStatementInternal.h Implementation-only interface and shared logix mix-in corresponding to mozIStorageBaseStatement. Both Statement and AsyncStatement inherit from this. The interface aspect makes them look the same to implementation innards that aren't publicly accessible. The mix-in avoids code duplication in common implementations of mozIStorageBaseStatement, albeit with some minor performance/space overhead because we have to use defines to officially implement the methods on Statement/AsyncStatement (and proxy to this base class.) 14204
style.txt 4303
TelemetryVFS.cpp RAII class for measuring how long io takes on/off main thread 23303
test 3
VacuumManager.cpp 11488
VacuumManager.h Obtains the VacuumManager object. 1099
variant 2
Variant_inl.h Note: This file is included by Variant.h. 3706
Variant.cpp Return the data type of the given variant. This method used to be exposed to XPCOM, but since bug 1507540 it's marked [notxpcom] in the interface definition, so we need this C function to access it from Rust. 1822
Variant.h 78888042-0fa3-4f7a-8b19-7996f99bf1aa 13400
variantToSQLiteT_impl.h 4309