angd-dev/data-lite-core
1
0
Fork 0
Code Pull Requests Releases Activity

Refactor entire codebase and rewrite documentation

Browse Source
This commit is contained in:
Oleksii Zghurskyi
2025-10-10 18:06:34 +03:00
parent b4e9755c15
commit 8e471f2b9f
74 changed files with 3405 additions and 4149 deletions
Download Patch File Download Diff File Expand all files Collapse all files

56
Sources/DataLiteCore/Enums/Synchronous.swift
View File

@@ -1,45 +1,41 @@
import Foundation
/// Represents different synchronous modes available for an SQLite database.
/// Represents the available synchronous modes for an SQLite database.
///
/// The synchronous mode determines how SQLite handles data synchronization with the database.
/// For more details, refer to [Synchronous Pragma](https://www.sqlite.org/pragma.html#pragma_synchronous).
public enum Synchronous: UInt8, SQLiteRawRepresentable {
/// Synchronous mode off. Disables synchronization for maximum performance.
/// The synchronous mode controls how thoroughly SQLite ensures that data is physically written to
/// disk. It defines the balance between durability, consistency, and performance during commits.
///
/// - SeeAlso: [PRAGMA synchronous](https://sqlite.org/pragma.html#pragma_synchronous)
public enum Synchronous: UInt8, SQLiteRepresentable {
/// Disables synchronization for maximum performance.
///
/// With synchronous OFF, SQLite continues without syncing as soon as it has handed data off
/// to the operating system. If the application running SQLite crashes, the data will be safe,
/// but the database might become corrupted if the operating system crashes or the computer loses
/// power before the data is written to the disk surface. On the other hand, commits can be orders
/// of magnitude faster with synchronous OFF.
/// With `synchronous=OFF`, SQLite does not wait for data to reach non-volatile storage before
/// continuing. The database may become inconsistent if the operating system crashes or power is
/// lost, although application-level crashes do not cause corruption.
/// Best suited for temporary databases or rebuildable data.
case off = 0
/// Normal synchronous mode.
/// Enables normal synchronization.
///
/// The SQLite database engine syncs at the most critical moments, but less frequently
/// than in FULL mode. While there is a very small chance of corruption in
/// `journal_mode=DELETE` on older filesystems during a power failure, WAL
/// mode is safe from corruption with synchronous=NORMAL. Modern filesystems
/// likely make DELETE mode safe too. However, WAL mode in synchronous=NORMAL
/// loses some durability, as a transaction committed in WAL mode might roll back
/// after a power loss or system crash. Transactions are still durable across application
/// crashes regardless of the synchronous setting or journal mode. This setting is a
/// good choice for most applications running in WAL mode.
/// SQLite performs syncs only at critical points. In WAL mode, this guarantees consistency but
/// not full durability: the most recent transactions might be lost after a power failure. In
/// rollback journal mode, there is a very small chance of corruption on older filesystems.
/// Recommended for most use cases where performance is preferred over strict durability.
case normal = 1
/// Full synchronous mode.
/// Enables full synchronization.
///
/// Uses the xSync method of the VFS to ensure that all content is safely written
/// to the disk surface prior to continuing. This ensures that an operating system
/// crash or power failure will not corrupt the database. FULL synchronous is very
/// safe but also slower. It is the most commonly used synchronous setting when
/// not in WAL mode.
/// SQLite calls the VFS `xSync` method to ensure that all data is written to disk before
/// continuing. Prevents corruption even after a system crash or power loss. Default mode for
/// rollback journals and fully ACID-compliant in WAL mode. Provides strong consistency and
/// isolation; durability may depend on filesystem behavior.
case full = 2
/// Extra synchronous mode.
/// Enables extra synchronization for maximum durability.
///
/// Similar to FULL mode, but ensures the directory containing the rollback journal
/// is synced after the journal is unlinked, providing additional durability in case of
/// power loss shortly after a commit.
/// Extends `FULL` by also syncing the directory that contained the rollback journal after it
/// is removed, ensuring durability even if power is lost immediately after a commit. Guarantees
/// full ACID compliance in both rollback and WAL modes. Recommended for systems where
/// durability is more important than performance.
case extra = 3
}