83 lines
3.9 KiB
Swift
83 lines
3.9 KiB
Swift
import Foundation
|
|
|
|
/// Represents the journal modes available for an SQLite database.
|
|
///
|
|
/// The journal mode determines how the database handles transactions and how it
|
|
/// maintains the journal for rollback and recovery. For more details, refer to
|
|
/// [Journal Mode Pragma](https://www.sqlite.org/pragma.html#pragma_journal_mode).
|
|
public enum JournalMode: String, SQLiteRawRepresentable {
|
|
/// DELETE journal mode.
|
|
///
|
|
/// This is the default behavior. The rollback journal is deleted at the conclusion
|
|
/// of each transaction. The delete operation itself causes the transaction to commit.
|
|
/// For more details, refer to the
|
|
/// [Atomic Commit In SQLite](https://www.sqlite.org/atomiccommit.html).
|
|
case delete
|
|
|
|
/// TRUNCATE journal mode.
|
|
///
|
|
/// In this mode, the rollback journal is truncated to zero length at the end of each transaction
|
|
/// instead of being deleted. On many systems, truncating a file is much faster than deleting it
|
|
/// because truncating does not require modifying the containing directory.
|
|
case truncate
|
|
|
|
/// PERSIST journal mode.
|
|
///
|
|
/// In this mode, the rollback journal is not deleted at the end of each transaction. Instead,
|
|
/// the header of the journal is overwritten with zeros. This prevents other database connections
|
|
/// from rolling the journal back. The PERSIST mode is useful as an optimization on platforms
|
|
/// where deleting or truncating a file is more expensive than overwriting the first block of a file
|
|
/// with zeros. For additional configuration, refer to
|
|
/// [journal_size_limit](https://www.sqlite.org/pragma.html#pragma_journal_size_limit).
|
|
case persist
|
|
|
|
/// MEMORY journal mode.
|
|
///
|
|
/// In this mode, the rollback journal is stored entirely in volatile RAM rather than on disk.
|
|
/// This saves disk I/O but at the expense of database safety and integrity. If the application
|
|
/// crashes during a transaction, the database file will likely become corrupt.
|
|
case memory
|
|
|
|
/// Write-Ahead Logging (WAL) journal mode.
|
|
///
|
|
/// This mode uses a write-ahead log instead of a rollback journal to implement transactions.
|
|
/// The WAL mode is persistent, meaning it stays in effect across multiple database connections
|
|
/// and persists even after closing and reopening the database. For more details, refer to the
|
|
/// [Write-Ahead Logging](https://www.sqlite.org/wal.html).
|
|
case wal
|
|
|
|
/// OFF journal mode.
|
|
///
|
|
/// In this mode, the rollback journal is completely disabled, meaning no rollback journal is ever created.
|
|
/// This disables SQLite's atomic commit and rollback capabilities. The `ROLLBACK` command will no longer work
|
|
/// and behaves in an undefined way. Applications must avoid using the `ROLLBACK` command when the journal mode is OFF.
|
|
/// If the application crashes in the middle of a transaction, the database file will likely become corrupt,
|
|
/// as there is no way to unwind partially completed operations. For example, if a duplicate entry causes a
|
|
/// `CREATE UNIQUE INDEX` statement to fail halfway through, it will leave behind a partially created index,
|
|
/// resulting in a corrupted database state.
|
|
case off
|
|
|
|
public var rawValue: String {
|
|
switch self {
|
|
case .delete: "DELETE"
|
|
case .truncate: "TRUNCATE"
|
|
case .persist: "PERSIST"
|
|
case .memory: "MEMORY"
|
|
case .wal: "WAL"
|
|
case .off: "OFF"
|
|
}
|
|
}
|
|
|
|
public init?(rawValue: String) {
|
|
switch rawValue.uppercased() {
|
|
case "DELETE": self = .delete
|
|
case "TRUNCATE": self = .truncate
|
|
case "PERSIST": self = .persist
|
|
case "MEMORY": self = .memory
|
|
case "WAL": self = .wal
|
|
case "OFF": self = .off
|
|
default: return nil
|
|
}
|
|
}
|
|
}
|