Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
swift generated interface
import Foundation
/**
* Welcome to YapDatabase!
*
* The project page has a wealth of documentation if you have any questions.
* https://github.com/yapstudios/YapDatabase
*
* If you're new to the project you may want to visit the wiki.
* https://github.com/yapstudios/YapDatabase/wiki
*
* From a single YapDatabase instance you can create multiple connections.
* Each connection is thread-safe and may be used concurrently with other connections.
*
* Multiple connections can simultaneously read from the database.
* Multiple connections can simultaneously read from the database while another connection is modifying the database.
* For example, the main thread could be reading from the database via connection A,
* while a background thread is writing to the database via connection B.
*
* However, only a single connection may be writing to the database at any one time.
* This is an inherent limitation of the underlying sqlite database.
*
* A connection instance is thread-safe, and operates by serializing access to itself.
* Thus you can share a single connection between multiple threads.
* But for conncurrent access between multiple threads you must use multiple connections.
**/
public enum YapDatabasePolicy : Int {
case containment
case share
case copy
}
public var YapDatabaseEnforcePermittedTransactions: Int32 { get }
// 000001
// 000010
// 000100
// 001000
// 000011
// 001100
// 000101
// 001010
// 001111
// 010000
public struct YapDatabaseConnectionFlushMemoryFlags : OptionSet {
public init(rawValue: UInt)
public static var caches: YapDatabaseConnectionFlushMemoryFlags { get }
public static var statements: YapDatabaseConnectionFlushMemoryFlags { get }
public static var `internal`: YapDatabaseConnectionFlushMemoryFlags { get }
public static var all: YapDatabaseConnectionFlushMemoryFlags { get }
}
open class YapDatabaseConnection : NSObject {
/**
* A database connection maintains a strong reference to its parent.
*
* This is to enforce the following core architecture rule:
* A database instance cannot be deallocated if a corresponding connection is stil alive.
**/
open var database: YapDatabase { get }
/**
* The optional name property assists in debugging.
* It is only used internally for log statements.
**/
open var name: String
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/**
* Each database connection maintains an independent cache of deserialized objects.
* This reduces disk IO and the overhead of the deserialization process.
* You can optionally configure the cache size, or disable it completely.
*
* The cache is properly kept in sync with the atomic snapshot architecture of the database system.
*
* You can configure the objectCache at any time, including within readBlocks or readWriteBlocks.
* To disable the object cache entirely, set objectCacheEnabled to NO.
* To use an inifinite cache size, set the objectCacheLimit to zero.
*
* By default the objectCache is enabled and has a limit of 250.
*
* New connections will inherit the default values set by the parent database object.
* Thus the default values for new connection instances are configurable.
*
* @see YapDatabase defaultObjectCacheEnabled
* @see YapDatabase defaultObjectCacheLimit
*
* Also see the wiki for a bit more info:
* https://github.com/yapstudios/YapDatabase/wiki/Cache
**/
open var objectCacheEnabled: Bool
open var objectCacheLimit: UInt
/**
* Each database connection maintains an independent cache of deserialized metadata.
* This reduces disk IO and the overhead of the deserialization process.
* You can optionally configure the cache size, or disable it completely.
*
* The cache is properly kept in sync with the atomic snapshot architecture of the database system.
*
* You can configure the metadataCache at any time, including within readBlocks or readWriteBlocks.
* To disable the metadata cache entirely, set metadataCacheEnabled to NO.
* To use an inifinite cache size, set the metadataCacheLimit to zero.
*
* By default the metadataCache is enabled and has a limit of 250.
*
* New connections will inherit the default values set by the parent database object.
* Thus the default values for new connection instances are configurable.
*
* @see YapDatabase defaultMetadataCacheEnabled
* @see YapDatabase defaultMetadataCacheLimit
*
* Also see the wiki for a bit more info:
* https://github.com/yapstudios/YapDatabase/wiki/Cache
**/
open var metadataCacheEnabled: Bool
open var metadataCacheLimit: UInt
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/**
* YapDatabase can use various optimizations to reduce overhead and memory footprint.
* The policy properties allow you to opt in to these optimizations when ready.
*
* The default value is YapDatabasePolicyContainment.
*
* It is the slowest, but also the safest policy.
* The other policies require a little more work, and little deeper understanding.
*
* These optimizations are discussed extensively in the wiki article "Performance Pro":
* https://github.com/yapstudios/YapDatabase/wiki/Performance-Pro
**/
open var objectPolicy: YapDatabasePolicy
open var metadataPolicy: YapDatabasePolicy
/**
* When architecting your application, you will likely create a few dedicated connections for particular uses.
* This property allows you to enforce only allowed transaction types for your dedicated connections.
*
* --- Example 1: ---
*
* You have a connection designed for use on the main thread which uses a longLivedReadTransaction.
* Ideally this connection has the following constraints:
* - May only be used on the main thread
* - Can only be used for synchronous read transactions
*
* The idea is to ensure that a read transaction on the main thread never blocks.
* Thus you don't want background threads potentially tying up the connection.
* Remember: transactions go through a serial per-connection queue.
* And similarly, you don't want asynchronous operations of any kind. As that would be the equivalent of
* using the connection on a background thread.
*
* To enforce this, you can do something like this within your app:
*
* uiDatabaseConnection.permittedTransactions = YDB_SyncReadTransaction | YDB_MainThreadOnly;
* [uiDatabaseConnection beginLongLivedReadTransaction];
*
* --- Example 2: ---
*
* You have a dedicated connection designed for read-only operations in background tasks.
* And you want to make sure that no read-write transactions are accidentally invoked on this connection,
* as that would slow your background tasks (which are designed to asynchronous, but generally very fast).
*
* To enforce this, you can do something like this within your app:
*
* roDatabaseConnection.permittedTransactions = YDB_AnyReadTransaction;
*
* --- Example 3: ---
*
* You have an internal databaseConnection within some highly asynchronous manager class.
* You've designed just about every method to be asynchronous,
* and you want to make sure you always remember to use asynchronous transactions.
*
* So, for debugging purposes, you do something like this:
*
* #if DEBUG
* databaseConnection.permittedTransactions = YBD_AnyAsyncTransaction;
* #endif
*
*
* The default value is YDB_AnyTransaction.
**/
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/**
* The snapshot number is the internal synchronization state primitive for the connection.
* It's generally only useful for database internals,
* but it can sometimes come in handy for general debugging of your app.
*
* The snapshot is a simple 64-bit number that gets incremented upon every readwrite transaction
* that makes modifications to the database. Due to the concurrent architecture of YapDatabase,
* there may be multiple concurrent connections that are inspecting the database at similar times,
* yet they are looking at slightly different "snapshots" of the database.
*
* The snapshot number may thus be inspected to determine (in a general fashion) what state the connection
* is in compared with other connections.
*
* You may also query YapDatabase.snapshot to determine the most up-to-date snapshot among all connections.
*
* Example:
*
* YapDatabase *database = [[YapDatabase alloc] init...];
* database.snapshot; // returns zero
*
* YapDatabaseConnection *connection1 = [database newConnection];
* YapDatabaseConnection *connection2 = [database newConnection];
*
* connection1.snapshot; // returns zero
* connection2.snapshot; // returns zero
*
* [connection1 readWriteWithBlock:^(YapDatabaseReadWriteTransaction *transaction){
* [transaction setObject:objectA forKey:keyA];
* }];
*
* database.snapshot; // returns 1
* connection1.snapshot; // returns 1
* connection2.snapshot; // returns 1
*
* [connection1 asyncReadWriteWithBlock:^(YapDatabaseReadWriteTransaction *transaction){
* [transaction setObject:objectB forKey:keyB];
* [NSThread sleepForTimeInterval:1.0]; // sleep for 1 second
*
* connection1.snapshot; // returns 1 (we know it will turn into 2 once the transaction completes)
* } completion:^{
*
* connection1.snapshot; // returns 2
* }];
*
* [connection2 asyncReadWithBlock:^(YapDatabaseReadTransaction *transaction){
* [NSThread sleepForTimeInterval:5.0]; // sleep for 5 seconds
*
* connection2.snapshot; // returns 1. See why?
* }];
*
* It's because connection2 started its transaction when the database was in snapshot 1.
* Thus, for the duration of its transaction, the database remains in that state.
*
* However, once connection2 completes its transaction, it will automatically update itself to snapshot 2.
*
* In general, the snapshot is primarily for internal use.
* However, it may come in handy for some tricky edge-case bugs (why doesn't my connection see that other commit?)
**/
open var snapshot: UInt64 { get }
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/**
* Read-only access to the database.
*
* The given block can run concurrently with sibling connections,
* regardless of whether the sibling connections are executing read-only or read-write transactions.
*
* The only time this method ever blocks is if another thread is currently using this connection instance
* to execute a readBlock or readWriteBlock. Recall that you may create multiple connections for concurrent access.
*
* This method is synchronous.
**/
open func read(_ block: @escaping (YapDatabaseReadTransaction) -> Swift.Void)
/**
* Read-write access to the database.
*
* Only a single read-write block can execute among all sibling connections.
* Thus this method may block if another sibling connection is currently executing a read-write block.
**/
open func readWrite(_ block: @escaping (YapDatabaseReadWriteTransaction) -> Swift.Void)
/**
* Read-only access to the database.
*
* The given block can run concurrently with sibling connections,
* regardless of whether the sibling connections are executing read-only or read-write transactions.
*
* This method is asynchronous.
**/
open func asyncRead(_ block: @escaping (YapDatabaseReadTransaction) -> Swift.Void)
/**
* Read-only access to the database.
*
* The given block can run concurrently with sibling connections,
* regardless of whether the sibling connections are executing read-only or read-write transactions.
*
* This method is asynchronous.
*
* An optional completion block may be used.
* The completionBlock will be invoked on the main thread (dispatch_get_main_queue()).
**/
open func asyncRead(_ block: @escaping (YapDatabaseReadTransaction) -> Swift.Void, completionBlock: (() -> Swift.Void)? = nil)
/**
* Read-only access to the database.
*
* The given block can run concurrently with sibling connections,
* regardless of whether the sibling connections are executing read-only or read-write transactions.
*
* This method is asynchronous.
*
* An optional completion block may be used.
* Additionally the dispatch_queue to invoke the completion block may also be specified.
* If NULL, dispatch_get_main_queue() is automatically used.
**/
open func asyncRead(_ block: @escaping (YapDatabaseReadTransaction) -> Swift.Void, completionQueue: DispatchQueue?, completionBlock: (() -> Swift.Void)? = nil)
/**
* Read-write access to the database.
*
* Only a single read-write block can execute among all sibling connections.
* Thus this method may block if another sibling connection is currently executing a read-write block.
*
* This method is asynchronous.
**/
open func asyncReadWrite(_ block: @escaping (YapDatabaseReadWriteTransaction) -> Swift.Void)
/**
* Read-write access to the database.
*
* Only a single read-write block can execute among all sibling connections.
* Thus the execution of the block may be delayed if another sibling connection
* is currently executing a read-write block.
*
* This method is asynchronous.
*
* An optional completion block may be used.
* The completionBlock will be invoked on the main thread (dispatch_get_main_queue()).
**/
open func asyncReadWrite(_ block: @escaping (YapDatabaseReadWriteTransaction) -> Swift.Void, completionBlock: (() -> Swift.Void)? = nil)
/**
* Read-write access to the database.
*
* Only a single read-write block can execute among all sibling connections.
* Thus the execution of the block may be delayed if another sibling connection
* is currently executing a read-write block.
*
* This method is asynchronous.
*
* An optional completion block may be used.
* Additionally the dispatch_queue to invoke the completion block may also be specified.
* If NULL, dispatch_get_main_queue() is automatically used.
**/
open func asyncReadWrite(_ block: @escaping (YapDatabaseReadWriteTransaction) -> Swift.Void, completionQueue: DispatchQueue?, completionBlock: (() -> Swift.Void)? = nil)
/**
* It's sometimes useful to find out when all previously queued transactions on a connection have completed.
* For example, you may have multiple methods (perhaps scattered across multiple classes) that may queue
* asyncReadWriteTransaction's on a particular databaseConnection. And you'd like to know when all
* the queued readWriteTransactions have completed.
*
* One way to accomplish this is simply to queue an asyncReadTransaction on the databaseConnection.
* Since all transactions on a databaseConnection are queued onto a serial dispatch queue, you'll know that once
* your asyncReadTransaction is running, all previously scheduled transactions have completed.
*
* Although the above technique works, the 'flushTransactionsWithCompletionQueue:completionBlock:'
* is a more efficient way to accomplish this task. (And a more elegant & readable way too.)
*
* @param completionQueue
* The dispatch_queue to invoke the completionBlock on.
* If NULL, dispatch_get_main_queue() is automatically used.
*
* @param completionBlock
* The block to invoke once all previously scheduled transactions have completed.
**/
open func flushTransactions(withCompletionQueue completionQueue: DispatchQueue?, completionBlock: (() -> Swift.Void)? = nil)
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/**
* Invoke this method to start a long-lived read-only transaction.
* This allows you to effectively create a stable state for the connection.
* This is most often used for connections that service the main thread for UI data.
*
* For a complete discussion, please see the wiki page:
* https://github.com/yapstudios/YapDatabase/wiki/LongLivedReadTransactions
**/
open func beginLongLivedReadTransaction() -> [Notification]
open func endLongLivedReadTransaction() -> [Notification]
open func isInLongLivedReadTransaction() -> Bool
/**
* A long-lived read-only transaction is most often setup on a connection that is designed to be read-only.
* But sometimes we forget, and a read-write transaction gets added that uses the read-only connection.
* This will implicitly end the long-lived read-only transaction. Oops.
*
* This is a bug waiting to happen.
* And when it does happen, it will be one of those bugs that's nearly impossible to reproduce.
* So its better to have an early warning system to help you fix the bug before it occurs.
*
* For a complete discussion, please see the wiki page:
* https://github.com/yapstudios/YapDatabase/wiki/LongLivedReadTransactions
*
* In debug mode (#if DEBUG), these exceptions are turned ON by default.
* In non-debug mode (#if !DEBUG), these exceptions are turned OFF by default.
**/
open func enableExceptionsForImplicitlyEndingLongLivedReadTransaction()
open func disableExceptionsForImplicitlyEndingLongLivedReadTransaction()
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// Query for any change to a collection
/**
* A YapDatabaseModifiedNotification is posted for every readwrite transaction that makes changes to the database.
*
* Given one or more notifications, these methods allow you to easily
* query to see if a change affects a given collection, key, or combinary.
*
* This is most often used in conjunction with longLivedReadTransactions.
*
* For more information on longLivedReadTransaction, see the following wiki article:
* https://github.com/yapstudios/YapDatabase/wiki/LongLivedReadTransactions
**/
open func hasChange(forCollection collection: String, in notifications: [Notification]) -> Bool
open func hasObjectChange(forCollection collection: String, in notifications: [Notification]) -> Bool
open func hasMetadataChange(forCollection collection: String, in notifications: [Notification]) -> Bool
// Query for a change to a particular key/collection tuple
open func hasChange(forKey key: String, inCollection collection: String, in notifications: [Notification]) -> Bool
open func hasObjectChange(forKey key: String, inCollection collection: String, in notifications: [Notification]) -> Bool
open func hasMetadataChange(forKey key: String, inCollection collection: String, in notifications: [Notification]) -> Bool
// Query for a change to a particular set of keys in a collection
open func hasChange(forAnyKeys keys: Set<AnyHashable>, inCollection collection: String, in notifications: [Notification]) -> Bool
open func hasObjectChange(forAnyKeys keys: Set<AnyHashable>, inCollection collection: String, in notifications: [Notification]) -> Bool
open func hasMetadataChange(forAnyKeys keys: Set<AnyHashable>, inCollection collection: String, in notifications: [Notification]) -> Bool
// Advanced query techniques
/**
* Returns YES if [transaction removeAllObjectsInCollection:] was invoked on the collection,
* or if [transaction removeAllObjectsInAllCollections] was invoked
* during any of the commits represented by the given notifications.
*
* If this was the case then YapDatabase may not have tracked every single key within the collection.
* And thus a key that was removed via clearing the collection may not show up while enumerating changedKeys.
*
* This method is designed to be used in conjunction with the enumerateChangedKeys.... methods (below).
* The hasChange... methods (above) already take this into account.
**/
open func didClearCollection(_ collection: String, in notifications: [Notification]) -> Bool
/**
* Returns YES if [transaction removeAllObjectsInAllCollections] was invoked
* during any of the commits represented by the given notifications.
*
* If this was the case then YapDatabase may not have tracked every single key within every single collection.
* And thus a key that was removed via clearing the database may not show up while enumerating changedKeys.
*
* This method is designed to be used in conjunction with the enumerateChangedKeys.... methods (below).
* The hasChange... methods (above) already take this into account.
**/
open func didClearAllCollections(in notifications: [Notification]) -> Bool
/**
* Allows you to enumerate all the changed keys in the given collection, for the given commits.
*
* Keep in mind that if [transaction removeAllObjectsInCollection:] was invoked on the given collection
* or [transaction removeAllObjectsInAllCollections] was invoked
* during any of the commits represented by the given notifications,
* then the key may not be included in the enumeration.
* You must use didClearCollection:inNotifications: or didClearAllCollectionsInNotifications:
* if you need to handle that case.
*
* @see didClearCollection:inNotifications:
* @see didClearAllCollectionsInNotifications:
**/
open func enumerateChangedKeys(inCollection collection: String, in notifications: [Notification], using block: @escaping (String, UnsafeMutablePointer<ObjCBool>) -> Swift.Void)
/**
* Allows you to enumerate all the changed collection/key tuples for the given commits.
*
* Keep in mind that if [transaction removeAllObjectsInCollection:] was invoked on the given collection
* or [transaction removeAllObjectsInAllCollections] was invoked
* during any of the commits represented by the given notifications,
* then the collection/key tuple may not be included in the enumeration.
* You must use didClearCollection:inNotifications: or didClearAllCollectionsInNotifications:
* if you need to handle that case.
*
* @see didClearCollection:inNotifications:
* @see didClearAllCollectionsInNotifications:
**/
open func enumerateChangedCollectionKeys(in notifications: [Notification], using block: @escaping (UnsafeMutablePointer<Int32>, UnsafeMutablePointer<ObjCBool>) -> Swift.Void)
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/**
* Creates or fetches the extension with the given name.
* If this connection has not yet initialized the proper extension connection, it is done automatically.
*
* @return
* A subclass of YapDatabaseExtensionConnection,
* according to the type of extension registered under the given name.
*
* One must register an extension with the database before it can be accessed from within connections or transactions.
* After registration everything works automatically using just the registered extension name.
*
* @see YapDatabase registerExtension:withName:
**/
open func `extension`(_ extensionName: String) -> YapDatabaseExtensionConnection
open func ext(_ extensionName: String) -> YapDatabaseExtensionConnection // <-- Shorthand (same as extension: method)
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/**
* This method may be used to flush the internal caches used by the connection,
* as well as flushing pre-compiled sqlite statements.
* Depending upon how often you use the database connection,
* you may want to be more or less aggressive on how much stuff you flush.
*
* YapDatabaseConnectionFlushMemoryFlags_None:
* No-op. Doesn't flush anything.
*
* YapDatabaseConnectionFlushMemoryFlags_Caches:
* Flushes all caches, including the object cache and metadata cache.
*
* YapDatabaseConnectionFlushMemoryFlags_Statements:
* Flushes all pre-compiled sqlite statements.
*
* YapDatabaseConnectionFlushMemoryFlags_Internal
* Flushes internal memory used by sqlite instance via sqlite_db_release_memory.
* Generally this means cached database pages.
*
* YapDatabaseConnectionFlushMemoryFlags_All:
* Full flush of everything (caches, statements, internal)
**/
open func flushMemory(with flags: YapDatabaseConnectionFlushMemoryFlags)
/**
* When a UIApplicationDidReceiveMemoryWarningNotification is received,
* the code automatically invokes flushMemoryWithFlags and passes the set flags.
*
* The default value is YapDatabaseConnectionFlushMemoryFlags_All.
*
* @see flushMemoryWithFlags:
**/
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/**
* Returns the current synchronous configuration via "PRAGMA synchronous;".
* Allows you to verify that sqlite accepted your synchronous configuration request.
**/
open func pragmaSynchronous() -> String
/**
* Returns the current page_size configuration via "PRAGMA page_size;".
* Allows you to verify that sqlite accepted your page_size configuration request.
**/
open func pragmaPageSize() -> Int
/**
* Returns the currently memory mapped I/O configureation via "PRAGMA mmap_size;".
* Allows you to verify that sqlite accepted your mmap_size configuration request.
*
* Memory mapping may be disabled by sqlite's compile-time options.
* Or it may restrict the mmap_size to something smaller than requested.
**/
open func pragmaMMapSize() -> Int
/**
* Upgrade Notice:
*
* The "auto_vacuum=FULL" was not properly set until YapDatabase v2.5.
* And thus if you have an app that was using YapDatabase prior to this version,
* then the existing database file will continue to operate in "auto_vacuum=NONE" mode.
* This means the existing database file won't be properly truncated as you delete information from the db.
* That is, the data will be removed, but the pages will be moved to the freelist,
* and the file itself will remain the same size on disk. (I.e. the file size can grow, but not shrink.)
* To correct this problem, you should run the vacuum operation at least once.
* After it is run, the "auto_vacuum=FULL" mode will be set,
* and the database file size will automatically shrink in the future (as you delete data).
*
* @returns Result from "PRAGMA auto_vacuum;" command, as a readable string:
* - NONE
* - FULL
* - INCREMENTAL
* - UNKNOWN (future proofing)
*
* If the return value is NONE, then you should run the vacuum operation at some point
* in order to properly reconfigure the database.
*
* Concerning Method Invocation:
*
* You can invoke this method as a standalone method on the connection:
*
* NSString *value = [databaseConnection pragmaAutoVacuum]
*
* Or you can invoke this method within a transaction:
*
* [databaseConnection asyncReadWithBlock:^(YapDatabaseReadTransaction *transaction){
* NSString *value = [databaseConnection pragmaAutoVacuum];
* }];
**/
open func pragmaAutoVacuum() -> String
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/**
* Performs a VACUUM on the sqlite database.
*
* This method operates as a synchronous ReadWrite "transaction".
* That is, it behaves in a similar fashion, and you may treat it as if it is a ReadWrite transaction.
*
* For more infomation on the VACUUM operation, see the sqlite docs:
* http://sqlite.org/lang_vacuum.html
*
* Remember that YapDatabase operates in WAL mode, with "auto_vacuum=FULL" set.
*
* @see pragmaAutoVacuum
**/
open func vacuum()
/**
* Performs a VACUUM on the sqlite database.
*
* This method operates as an asynchronous readWrite "transaction".
* That is, it behaves in a similar fashion, and you may treat it as if it is a ReadWrite transaction.
*
* For more infomation on the VACUUM operation, see the sqlite docs:
* http://sqlite.org/lang_vacuum.html
*
* Remember that YapDatabase operates in WAL mode, with "auto_vacuum=FULL" set.
*
* An optional completion block may be used.
* The completionBlock will be invoked on the main thread (dispatch_get_main_queue()).
*
* @see pragmaAutoVacuum
**/
open func asyncVacuum(completionBlock: (() -> Swift.Void)? = nil)
/**
* Performs a VACUUM on the sqlite database.
*
* This method operates as an asynchronous readWrite "transaction".
* That is, it behaves in a similar fashion, and you may treat it as if it is a ReadWrite transaction.
*
* For more infomation on the VACUUM operation, see the sqlite docs:
* http://sqlite.org/lang_vacuum.html
*
* Remember that YapDatabase operates in WAL mode, with "auto_vacuum=FULL" set.
*
* An optional completion block may be used.
* Additionally the dispatch_queue to invoke the completion block may also be specified.
* If NULL, dispatch_get_main_queue() is automatically used.
*
* @see pragmaAutoVacuum
**/
open func asyncVacuum(withCompletionQueue completionQueue: DispatchQueue?, completionBlock: (() -> Swift.Void)? = nil)
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/**
* This method backs up the database by exporting all the tables to another sqlite database.
*
* This method operates as a synchronous ReadWrite "transaction".
* That is, it behaves in a similar fashion, and you may treat it as if it is a ReadWrite transaction.
*
* The database will be backed up as it exists at the moment this transaction operates.
* That is, it will backup everything in the sqlite file, as well as everything in the WAL file.
*
* For more information on the BACKUP operation, see the sqlite docs:
* https://www.sqlite.org/c3ref/backup_finish.html
*
* As stated in the sqlite docs, it is your responsibilty to ensure that nothing else is
* currently using the backupDatabase.
**/
open func backup(toPath backupDatabasePath: String) -> Error
/**
* This method backs up the database by exporting all the tables to another sqlite database.
*
* This method operates as an asynchronous readWrite "transaction".
* That is, it behaves in a similar fashion, and you may treat it as if it is a ReadWrite transaction.
*
* The database will be backed up as it exists at the moment this transaction operates.
* That is, it will backup everything in the sqlite file, as well as everything in the WAL file.
*
* An optional completion block may be used.
* The completionBlock will be invoked on the main thread (dispatch_get_main_queue()).
*
* For more information on the BACKUP operation, see the sqlite docs:
* https://www.sqlite.org/c3ref/backup_finish.html
*
* As stated in the sqlite docs, it is your responsibilty to ensure that nothing else is
* currently using the backupDatabase.
*
* @return
* A NSProgress instance that may be used to track the backup progress.
* The progress in cancellable, meaning that invoking [progress cancel] will abort the backup operation.
**/
open func asyncBackup(toPath backupDatabasePath: String, completionBlock: ((Error) -> Swift.Void)? = nil) -> Progress
/**
* This method backs up the database by exporting all the tables to another sqlite database.
*
* This method operates as an asynchronous readWrite "transaction".
* That is, it behaves in a similar fashion, and you may treat it as if it is a ReadWrite transaction.
*
* The database will be backed up as it exists at the moment this transaction operates.
* That is, it will backup everything in the sqlite file, as well as everything in the WAL file.
*
* An optional completion block may be used.
* Additionally the dispatch_queue to invoke the completion block may also be specified.
* If NULL, dispatch_get_main_queue() is automatically used.
*
* For more information on the BACKUP operation, see the sqlite docs:
* https://www.sqlite.org/c3ref/backup_finish.html
*
* As stated in the sqlite docs, it is your responsibilty to ensure that nothing else is
* currently using the backupDatabase.
*
* @return
* A NSProgress instance that may be used to track the backup progress.
* The progress in cancellable, meaning that invoking [progress cancel] will abort the backup operation.
**/
open func asyncBackup(toPath backupDatabasePath: String, completionQueue: DispatchQueue?, completionBlock: ((Error) -> Swift.Void)? = nil) -> Progress
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.