Client API Reference

This document provides a reference for the SQLite functions provided by the sqlite-sync extension.

Index

• Configuration Functions
  • cloudsync_init()
  • cloudsync_enable()
  • cloudsync_disable()
  • cloudsync_is_enabled()
  • cloudsync_set_filter()
  • cloudsync_clear_filter()
  • cloudsync_cleanup()
  • cloudsync_terminate()
• Block-Level LWW Functions
  • cloudsync_set_column()
  • cloudsync_text_materialize()
• Helper Functions
  • cloudsync_version()
  • cloudsync_siteid()
  • cloudsync_db_version()
  • cloudsync_uuid()
• Schema Alteration Functions
  • cloudsync_begin_alter()
  • cloudsync_commit_alter()
• Network Functions
  • cloudsync_network_init()
  • cloudsync_network_cleanup()
  • cloudsync_network_set_token()
  • cloudsync_network_set_apikey()
  • cloudsync_network_send_changes()
  • cloudsync_network_receive_changes()
  • cloudsync_network_check_changes() (deprecated)
  • cloudsync_network_sync()
  • cloudsync_network_reset_sync_version()
  • cloudsync_network_has_unsent_changes()
  • cloudsync_network_logout()

Configuration Functions

cloudsync_init(table_name, [crdt_algo], [init_flags])

Description: Initializes a table for sqlite-sync synchronization. This function is idempotent and needs to be called only once per table on each site; configurations are stored in the database and automatically loaded with the extension.

Before initialization, cloudsync_init performs schema sanity checks to ensure compatibility with CRDT requirements and best practices. These checks include:

• Primary keys should not be auto-incrementing integers; GUIDs (UUIDs, ULIDs) are highly recommended to prevent multi-node collisions.
• All non-primary key NOT NULL columns must have a DEFAULT value.
• Note: Any write operation that includes a NULL value for a primary key column will be rejected with an error, even if SQLite would normally allow it due to a legacy behavior.

Schema Design Considerations:

When designing your database schema for SQLite Sync, follow these essential requirements:

• Primary Keys: Use TEXT primary keys with cloudsync_uuid() for globally unique identifiers. Avoid auto-incrementing integers.
• Column Constraints: All NOT NULL columns (except primary keys) must have DEFAULT values to prevent synchronization errors.
• UNIQUE Constraints: In multi-tenant scenarios, use composite UNIQUE constraints (e.g., UNIQUE(tenant_id, email)) instead of global uniqueness.
• Foreign Key Compatibility: Be aware of potential conflicts during CRDT merge operations and RLS policy interactions.
• Trigger Compatibility: Triggers may cause duplicate operations or be called multiple times due to column-by-column processing.

For comprehensive guidelines, see the Database Schema Recommendations.

The function supports three overloads:

• cloudsync_init(table_name): Uses the default ‘cls’ CRDT algorithm.
• cloudsync_init(table_name, crdt_algo): Specifies a CRDT algorithm (‘cls’, ‘dws’, ‘aws’, ‘gos’).
• cloudsync_init(table_name, crdt_algo, init_flags): Specifies an algorithm and a bitmask of initialization flags to control which schema sanity checks are skipped.

Parameters:

• table_name (TEXT): The name of the table to initialize.
• crdt_algo (TEXT, optional): The CRDT algorithm to use. Can be "cls", "dws", "aws", "gos". Defaults to "cls".
• init_flags (INTEGER, optional): A bitmask of flags that control initialization behavior. Defaults to 0 (no flags). Available flags:
  • 0 — No flags; all sanity checks are performed (default).
  • 1 (CLOUDSYNC_INIT_FLAG_SKIP_INT_PK_CHECK) — Skip the check that prevents the use of a single-column INTEGER primary key. Use with caution; globally unique primary keys (UUID/ULID) are strongly recommended.
  • 2 (CLOUDSYNC_INIT_FLAG_SKIP_NOT_NULL_DEFAULT_CHECK) — Skip the check that requires all NOT NULL non-PK columns to have a DEFAULT value.
  • 4 (CLOUDSYNC_INIT_FLAG_SKIP_NOT_NULL_PRIKEYS_CHECK) — Skip the check that rejects NULL primary key values.
  • Flags can be combined with bitwise OR (e.g., 3 skips both the integer PK check and the NOT NULL default check).

Returns: None.

Example:

-- Initialize a table with the default CLS algorithm
SELECT cloudsync_init('my_table');

-- Initialize a table with the Delete-Wins Set algorithm
SELECT cloudsync_init('my_table', 'dws');

-- Initialize a table with an integer primary key (skip the integer PK check)
SELECT cloudsync_init('my_table', 'cls', 1);

cloudsync_enable(table_name)

Description: Enables synchronization for the specified table.

Parameters:

• table_name (TEXT): The name of the table to enable.

Returns: None.

Example:

SELECT cloudsync_enable('my_table');

cloudsync_disable(table_name)

Description: Disables synchronization for the specified table.

Parameters:

• table_name (TEXT): The name of the table to disable.

Returns: None.

Example:

SELECT cloudsync_disable('my_table');

cloudsync_is_enabled(table_name)

Description: Checks if synchronization is enabled for the specified table.

Parameters:

• table_name (TEXT): The name of the table to check.

Returns: 1 if enabled, 0 otherwise.

Example:

SELECT cloudsync_is_enabled('my_table');

cloudsync_set_filter(table_name, filter_expr)

Description: Sets a row-level filter expression on a synchronized table. Only rows that match the filter are tracked by the sync triggers; changes to rows that do not satisfy the expression are ignored and never replicated.

The filter expression is a standard SQL boolean expression written using bare column names (without a table or alias prefix). The extension automatically rewrites it with NEW. for INSERT/UPDATE triggers and OLD. for DELETE triggers. The expression is evaluated inside the trigger WHEN clause.

This function stores the filter in the table’s settings and immediately recreates the sync triggers to apply it. The filter persists across database reopens. Use cloudsync_clear_filter() to remove it.

Parameters:

• table_name (TEXT): The name of the synchronized table.
• filter_expr (TEXT): A SQL boolean expression referencing column names of the table. Only rows for which this expression evaluates to true are tracked for sync.

Returns: 1 on success.

Example:

-- Only sync tasks that are not marked as drafts
SELECT cloudsync_set_filter('tasks', "is_draft = 0");

-- Only sync rows belonging to a specific tenant
SELECT cloudsync_set_filter('orders', "tenant_id = 'acme'");

-- Combine conditions
SELECT cloudsync_set_filter('messages', "deleted = 0 AND type != 'ephemeral'");

cloudsync_clear_filter(table_name)

Description: Removes the row-level filter previously set with cloudsync_set_filter(). After clearing, all row changes in the table are tracked and replicated regardless of column values.

This function updates the stored settings and immediately recreates the sync triggers without a filter condition.

Parameters:

• table_name (TEXT): The name of the synchronized table.

Returns: 1 on success.

Example:

SELECT cloudsync_clear_filter('tasks');

cloudsync_cleanup(table_name)

Description: Removes the sqlite-sync synchronization mechanism from a specified table or all tables. This operation drops the associated _cloudsync metadata table and removes triggers from the target table(s). Use this function when synchronization is no longer desired for a table.

Parameters:

• table_name (TEXT): The name of the table to clean up.

Returns: None.

Example:

-- Clean up a single table
SELECT cloudsync_cleanup('my_table');

cloudsync_terminate()

Description: Releases all internal resources used by the sqlite-sync extension for the current database connection. This function should be called before closing the database connection to ensure that all prepared statements and allocated memory are freed. Failing to call this function can result in memory leaks or a failed sqlite3_close operation due to pending statements.

Parameters: None.

Returns: None.

Example:

-- Before closing the database connection
SELECT cloudsync_terminate();

Block-Level LWW Functions

cloudsync_set_column(table_name, col_name, key, value)

Description: Configures per-column settings for a synchronized table. This function is primarily used to enable block-level LWW on text columns, allowing fine-grained conflict resolution at the line (or paragraph) level instead of the entire cell.

When block-level LWW is enabled on a column, INSERT and UPDATE operations automatically split the text into blocks using a delimiter (default: newline \n) and track each block independently. During sync, changes are merged block-by-block, so concurrent edits to different parts of the same text are preserved.

Parameters:

• table_name (TEXT): The name of the synchronized table.
• col_name (TEXT): The name of the text column to configure.
• key (TEXT): The setting key. Supported keys:
  • 'algo' — Set the column algorithm. Use value 'block' to enable block-level LWW.
  • 'delimiter' — Set the block delimiter string. Only applies to columns with block-level LWW enabled.
• value (TEXT): The setting value.

Returns: None.

Example:

-- Enable block-level LWW on a column (splits text by newline by default)
SELECT cloudsync_set_column('notes', 'body', 'algo', 'block');

-- Set a custom delimiter (e.g., double newline for paragraph-level tracking)
SELECT cloudsync_set_column('notes', 'body', 'delimiter', '

');

cloudsync_text_materialize(table_name, col_name, pk_values...)

Description: Reconstructs the full text of a block-level LWW column from its individual blocks and writes the result back to the base table column. This is useful after a merge operation to ensure the column contains the up-to-date materialized text.

After a sync/merge, the column is updated automatically. This function is primarily useful for manual materialization or debugging.

Parameters:

• table_name (TEXT): The name of the table.
• col_name (TEXT): The name of the block-level LWW column.
• pk_values... (variadic): The primary key values identifying the row. For composite primary keys, pass each key value as a separate argument in declaration order.

Returns: 1 on success.

Example:

-- Materialize the body column for a specific row
SELECT cloudsync_text_materialize('notes', 'body', 'note-001');

-- With a composite primary key (e.g., PRIMARY KEY (tenant_id, doc_id))
SELECT cloudsync_text_materialize('docs', 'body', 'tenant-1', 'doc-001');

-- Read the materialized text
SELECT body FROM notes WHERE id = 'note-001';

Helper Functions

cloudsync_version()

Description: Returns the version of the sqlite-sync library.

Parameters: None.

Returns: The library version as a string.

Example:

SELECT cloudsync_version();
-- e.g., '1.0.0'

cloudsync_siteid()

Description: Returns the unique ID of the local site.

Parameters: None.

Returns: The site ID as a BLOB.

Example:

SELECT cloudsync_siteid();

cloudsync_db_version()

Description: Returns the current database version.

Parameters: None.

Returns: The database version as an INTEGER.

Example:

SELECT cloudsync_db_version();

cloudsync_uuid()

Description: Generates a new universally unique identifier (UUIDv7). This is useful for creating globally unique primary keys for new records, which is a best practice for CRDTs.

Parameters: None.

Returns: A new UUID as a TEXT value.

Example:

INSERT INTO products (id, name) VALUES (cloudsync_uuid(), 'New Product');

Schema Alteration Functions

cloudsync_begin_alter(table_name)

Description: Prepares a synchronized table for schema changes. This function must be called before altering the table. Failure to use cloudsync_begin_alter and cloudsync_commit_alter can lead to synchronization errors and data divergence.

Parameters:

• table_name (TEXT): The name of the table that will be altered.

Returns: None.

Example:

SELECT cloudsync_init('my_table');
-- ... later
SELECT cloudsync_begin_alter('my_table');
ALTER TABLE my_table ADD COLUMN new_column TEXT;
SELECT cloudsync_commit_alter('my_table');

cloudsync_commit_alter(table_name)

Description: Finalizes schema changes for a synchronized table. This function must be called after altering the table’s schema, completing the process initiated by cloudsync_begin_alter and ensuring CRDT data consistency.

Parameters:

• table_name (TEXT): The name of the table that was altered.

Returns: None.

Example:

SELECT cloudsync_init('my_table');
-- ... later
SELECT cloudsync_begin_alter('my_type');
ALTER TABLE my_table ADD COLUMN new_column TEXT;
SELECT cloudsync_commit_alter('my_table');

Network Functions

cloudsync_network_init(managedDatabaseId)

Description: Initializes the sqlite-sync network component. This function configures the endpoints for the CloudSync service and initializes the cURL library.

Parameters:

• managedDatabaseId (TEXT): The managed database identifier returned by the CloudSync service when a new database is registered for sync. For SQLiteCloud projects, this value can be obtained from the project’s CloudSync page on the dashboard.

Returns: None.

Example:

SELECT cloudsync_network_init('your-managed-database-id');

cloudsync_network_cleanup()

Description: Cleans up the sqlite-sync network component, releasing all resources allocated by cloudsync_network_init (memory, cURL handles).

Parameters: None.

Returns: None.

Example:

SELECT cloudsync_network_cleanup();

cloudsync_network_set_token(token)

Description: Sets the authentication token to be used for network requests. This token will be included in the Authorization header of all subsequent requests. For more information, refer to the Access Tokens documentation.

Parameters:

• token (TEXT): The authentication token.

Returns: None.

Example:

SELECT cloudsync_network_set_token('your_auth_token');

cloudsync_network_set_apikey(apikey)

Description: Sets the API key for network requests. This key is included in the Authorization header of all subsequent requests.

Parameters:

• apikey (TEXT): The API key.

Returns: None.

Example:

SELECT cloudsync_network_set_apikey('your_api_key');

Error handling

The sync functions follow a consistent error-handling contract:

This means: if you get JSON back, the server was reachable and the network protocol ran. If you get a SQL error, connectivity or configuration is broken.

cloudsync_network_send_changes()

Description: Sends all unsent local changes to the remote server.

The send path streams payloads through cloudsync_payload_chunks(), so payload_max_chunk_size also limits the payloads generated for network transport. Each generated chunk is uploaded/applied independently; the local send checkpoint is advanced only after the chunk stream completes successfully.

Chunk transport is transparent to the CloudSync backend. Each chunk is sent as a normal /apply payload, either inline as a base64 blob or through the upload url path. There is no separate chunk flag: old payloads, monolithic payloads, and v3 fragment payloads are distinguished by the payload format itself.

Parameters: None.

Returns: A JSON string with the send result:

{"send": {"status": "synced|syncing|out-of-sync|error", "localVersion": N, "serverVersion": N, "chunks": C, "bytes": B, "lastFailure": {...}}}

• send.status: The current sync state — "synced" (all changes confirmed), "syncing" (changes sent but not yet confirmed), "out-of-sync" (local changes pending or gaps detected), or "error".
• send.localVersion: The latest local database version.
• send.serverVersion: The latest version confirmed by the server.
• send.chunks: The number of payload chunks sent this call (a large push is split into multiple transport chunks bounded by payload_max_chunk_size). 0 when there were no local changes to send.
• send.bytes: The total serialized payload bytes sent this call (uncompressed cloudsync payload size, summed across chunks; not the compressed wire size).
• send.lastFailure (optional): Present only when the server reports a failed apply job. Forwarded verbatim from the server’s failures.apply and typically includes jobId, code, stage, message, retryable, and failedAt. It is emitted regardless of status so callers can detect server-side failures during "syncing" or even after the state has nominally recovered. This function is send/apply-scoped: server-reported check-job failures (failures.check) are not surfaced here — see cloudsync_network_receive_changes() and cloudsync_network_sync().

Example:

SELECT cloudsync_network_send_changes();
-- '{"send":{"status":"synced","localVersion":5,"serverVersion":5,"chunks":1,"bytes":2048}}'

-- With a server-reported failure (e.g. unknown schema hash on the server side):
-- '{"send":{"status":"out-of-sync","localVersion":1,"serverVersion":0,"chunks":1,"bytes":512,"lastFailure":{"jobId":44961,"code":"internal_error","stage":"apply_payload","message":"cloudsync operation failed: Cannot apply the received payload because the schema hash is unknown 4288148391734624266.","retryable":true,"failedAt":"2026-04-15T22:21:09.018606Z"}}}'

cloudsync_network_receive_changes([max_chunks])

Description: Receives new changes from the remote server and applies them to the local database. (Formerly cloudsync_network_check_changes(), which remains available as a deprecated alias — see below.)

If changes are already prepared for the local site, they are downloaded and applied. If nothing is ready yet, the server starts preparing a package asynchronously and this call returns having applied nothing; a later call retrieves it. This function does not wait/poll for preparation to finish — it applies what is available now. To force an update and wait for not-yet-ready changes, use cloudsync_network_sync(wait_ms, max_retries).

By default this function drains all currently-available chunks in one call. Pass max_chunks to cap how many chunks are applied per call, for caller-driven progress or traffic control:

-- Drain at most 5 chunks, loop until the stream is complete
SELECT cloudsync_network_receive_changes(5) ->> '$.receive.complete';

The drain position (the per-stream page cursor) is held in memory on the network context, so a capped drain resumes where it left off on the next call — the caller does not manage any cursor; it just loops while receive.complete is false. If the connection is closed or the process restarts mid-drain, the cursor is lost and the next call safely restarts the drain from the beginning of the stream: already-applied chunks are re-downloaded and re-applied idempotently, so no rows are skipped — only redundant download is incurred. This is safe because the durable receive checkpoint (check_dbversion/check_seq) only advances after a stream has been fully applied, never in the middle of a source db_version.

If the network is misconfigured or the remote server is unreachable, the function raises a SQL error. If the received payload cannot be applied locally (for example because of an unknown schema hash), the error is returned as a receive.error field in the JSON response. If the server reports an unresolved failed check job (e.g. an encode_changes failure), that failure is forwarded as a receive.lastFailure object.

Parameters:

• max_chunks (INTEGER, optional): Maximum number of chunks to apply this call. Omit or pass 0 (or negative) to drain everything available. A positive value caps the drain; receive.complete will be false when the cap stops a drain that still has pending chunks.

Returns: A JSON string with the receive result:

{"receive": {"rows": N, "tables": ["table1", "table2"], "chunks": C, "bytes": B, "complete": true, "error": "...", "lastFailure": {...}}}

• receive.rows: The total number of rows received and applied to the local database, summed across all chunks drained this call. 0 when the receive phase failed, when nothing was available, or when only intermediate fragments were staged without completing a value.
• receive.tables: An array of table names that received changes (the union across all drained chunks). Empty ([]) if no changes were applied or the receive phase failed.
• receive.chunks: The number of payload chunks applied by this call. 0 when nothing was ready, 1 for a single monolithic/inline page, and N for a drained N-chunk stream (bounded by max_chunks if given).
• receive.bytes: The total serialized payload bytes received this call (uncompressed cloudsync payload size, summed across chunks; transport-independent, not the compressed wire size). Useful for byte-budgeted draining together with max_chunks.
• receive.complete (boolean): true when the receive stream is fully drained (nothing pending), false when more chunks remain — because max_chunks capped the drain, or it stopped early. When false, call this function again to continue.
• receive.error (optional, string): Present when client-side cloudsync_payload_apply failed. Contains a human-readable error message describing why the received payload could not be applied.
• receive.lastFailure (optional, object): Present only when the server reports a failed check job. Forwarded verbatim from the server’s failures.check and typically includes jobId, dbVersion, seq, code, stage, message, retryable, and failedAt. Distinct from receive.error: receive.error describes a client-side apply failure (string), while receive.lastFailure describes a server-side check-job failure (object). Both can coexist in the same response. This function is check-scoped: server-reported apply-job failures (failures.apply) are not surfaced here — see cloudsync_network_send_changes() and cloudsync_network_sync().

Example:

SELECT cloudsync_network_receive_changes();
-- '{"receive":{"rows":3,"tables":["tasks"],"chunks":1,"bytes":820,"complete":true}}'

-- Capped drain with more pending (call again to continue):
-- '{"receive":{"rows":40,"tables":["docs"],"chunks":5,"bytes":1310720,"complete":false}}'

-- With a client-side apply error:
-- '{"receive":{"rows":0,"tables":[],"chunks":0,"bytes":0,"complete":true,"error":"Cannot apply the received payload because the schema hash is unknown 7218827471400075525."}}'

-- With a server-reported check-job failure:
-- '{"receive":{"rows":0,"tables":[],"chunks":0,"bytes":0,"complete":true,"lastFailure":{"jobId":456,"dbVersion":15,"seq":1,"code":"tenant_unreachable","stage":"encode_changes","message":"tenant check failed","retryable":true,"failedAt":"2026-04-24T10:22:00Z"}}}'

cloudsync_network_check_changes([max_chunks])

Deprecated: use cloudsync_network_receive_changes(). This name is retained as a thin alias for backward compatibility and will be removed in a future major version. It behaves identically, including the optional max_chunks argument and all returned fields.

cloudsync_network_sync([wait_ms], [max_retries])

Description: Performs a full synchronization cycle. This function has two overloads:

• cloudsync_network_sync(): Performs one send operation and one check operation.
• cloudsync_network_sync(wait_ms, max_retries): Performs one send operation and then downloads remote changes.

When the server delivers changes as a stream of chunks, this function drains the whole stream in a single call: as long as the next chunk is already available it is fetched back-to-back with no delay. wait_ms and max_retries are spent only while the server payload is not yet ready (the server is still preparing a package): in that case the function waits wait_ms and retries up to max_retries times. They are not consumed while paging through chunks that are already available.

Parameters:

• wait_ms (INTEGER, optional): The time to wait in milliseconds between retries while the server payload is not yet ready. Defaults to 100.
• max_retries (INTEGER, optional): The maximum number of poll attempts while the server payload is not yet ready. Defaults to 1.

Returns: A JSON string with the full sync result, combining send and receive:

{
  "send": {"status": "synced|syncing|out-of-sync|error", "localVersion": N, "serverVersion": N, "chunks": C, "bytes": B, "lastFailure": {...}},
  "receive": {"rows": N, "tables": ["table1", "table2"], "chunks": C, "bytes": B, "complete": true, "error": "...", "lastFailure": {...}}
}

• send.status: The current sync state — "synced", "syncing", "out-of-sync", or "error".
• send.localVersion: The latest local database version.
• send.serverVersion: The latest version confirmed by the server.
• send.chunks / send.bytes: Number of payload chunks sent and total serialized payload bytes sent during the send phase. Same semantics as in cloudsync_network_send_changes().
• send.lastFailure (optional): Same semantics as in cloudsync_network_send_changes() — forwarded verbatim from the server’s failures.apply whenever a failed apply job is reported, regardless of status.
• receive.rows: The total number of rows received and applied during the receive phase, summed across all chunks drained in this call. 0 when the receive phase failed.
• receive.tables: An array of table names that received changes (the union across all drained chunks). Empty ([]) if no changes were applied or the receive phase failed.
• receive.chunks: The number of payload chunks applied in this call. 0 when nothing was ready, 1 for a single monolithic/inline page, and N for a fully drained N-chunk stream. cloudsync_network_sync() always drains the whole stream (it does not cap chunks).
• receive.bytes: The total serialized payload bytes received this call (uncompressed cloudsync payload size, summed across chunks; not the compressed wire size). Same semantics as in cloudsync_network_receive_changes().
• receive.complete (boolean): true when the server stream was fully drained, false when the download stopped before the final chunk (an error occurred, or an internal safety bound was reached). When false, call cloudsync_network_sync() again to resume; re-delivered rows are idempotent.
• receive.error (optional, string): Present when client-side cloudsync_payload_apply failed (for example "Cannot apply the received payload because the schema hash is unknown 7218827471400075525."). The send result is always preserved so the caller can tell that local changes reached the server even when applying incoming changes failed. The receive drain stops immediately on apply errors, since failures like schema-hash mismatches do not heal across retries. Endpoint/network errors during the receive phase raise a SQL error instead.
• receive.lastFailure (optional, object): Same semantics as in cloudsync_network_receive_changes() — forwarded verbatim from the server’s failures.check whenever a failed check job is reported. Distinct from receive.error. cloudsync_network_sync() reports both send.lastFailure and receive.lastFailure when present.

Example:

-- Perform a single synchronization cycle
SELECT cloudsync_network_sync();
-- '{"send":{"status":"synced","localVersion":5,"serverVersion":5,"chunks":1,"bytes":2048},"receive":{"rows":3,"tables":["tasks"],"chunks":1,"bytes":820,"complete":true}}'

-- Perform a synchronization cycle with custom retry settings
SELECT cloudsync_network_sync(500, 3);
-- A large download drained as a multi-chunk stream in a single call:
-- '{"send":{"status":"synced","localVersion":42,"serverVersion":42,"chunks":0,"bytes":0},"receive":{"rows":1200,"tables":["docs"],"chunks":7,"bytes":1835008,"complete":true}}'

-- Receive phase failed but send phase completed — the error is surfaced in JSON, not as a SQL error:
-- '{"send":{"status":"synced","localVersion":5,"serverVersion":5,"chunks":1,"bytes":512},"receive":{"rows":0,"tables":[],"chunks":0,"bytes":0,"complete":false,"error":"Cannot apply the received payload because the schema hash is unknown 7218827471400075525."}}'

cloudsync_network_reset_sync_version()

Description: Resets local synchronization version numbers, forcing the next sync to fetch all changes from the server.

Parameters: None.

Returns: None.

Example:

SELECT cloudsync_network_reset_sync_version();

cloudsync_network_has_unsent_changes()

Description: Checks if there are any local changes that have not yet been sent to the remote server.

Parameters: None.

Returns: 1 if there are unsent changes, 0 otherwise.

Example:

SELECT cloudsync_network_has_unsent_changes();

cloudsync_network_logout()

Description: Logs out the current user and cleans up all local data from synchronized tables. This function deletes and then re-initializes synchronized tables, useful for switching users or resetting the local database. Warning: This function deletes all data from synchronized tables. Use with caution. Consider calling cloudsync_network_has_unsent_changes() before logout to check for unsent local changes and warn the user before data that has not been fully synchronized to the remote server is deleted.

Parameters: None.

Returns: None.

Example:

SELECT cloudsync_network_logout();