Read-only and production safety

DataKlin checks every statement before it reaches the database. On a read-only connection it refuses writes, and on any connection it asks before a destructive statement runs. A connection tagged Production always asks, and is marked wherever its consoles and results appear.

You set both on the Details tab of the connection dialog: the Read-only checkbox and the Environment tag (None, Development, Test, Staging or Production).

Read-only connections

On a read-only connection, DataKlin refuses writes, schema changes and statements it can’t classify before they reach the database. The result shows why, for example:

Blocked: this connection is read-only (statement classified as write: UPDATE)

Reads run as usual, and so do harmless session settings such as SET search_path or USE.

On PostgreSQL, MySQL, MariaDB and SQLite, DataKlin also puts the database session itself into read-only mode. The markers show which protection applies: database + DataKlin, or DataKlin statement checks only for a database without a read-only session.

DataKlin reads statements, not what a function does: SELECT of a function that changes data is caught only by the database’s read-only session. In DataKlin 0.2.0 and earlier, read-only was a label only.

Turn read-only on or off

• Click Read-only: on or Read-only: off in the status bar, or run Safety: Toggle Read-Only for the Open Connection from the command palette. It changes the open connection and saves the change.
• Turning read-only off on a production connection asks for confirmation first.

Confirming destructive statements

These statements ask for confirmation before they run:

• DROP of any object, TRUNCATE, and ALTER ... DROP
• DELETE or UPDATE without a WHERE, or with WHERE 1=1 or WHERE true
• statements DataKlin can’t classify (“DataKlin can’t tell what this statement does”)

The dialog shows each statement and the reasons, such as a DELETE without WHERE that affects every row of a table. Cancel has the focus, so pressing Enter never runs the statement. When you run a script, one dialog lists every statement that needs confirming, so you confirm once per run. Cancelling skips the rest of the script.

On a read-only connection these statements are refused, not confirmed.

Settings

• Settings → Safety → Confirm destructive statements: On every connection (the default) or On production connections only.
• On a connection that isn’t production, the dialog offers Don’t ask again for this connection. To be asked again, run Safety: Reset “Don’t Ask Again” for a Connection, or choose Reset “Don’t ask again” on the connection in the Connections view.

Production connections

A connection tagged Production gets extra protection, which can’t be turned off:

• Always confirm. Destructive statements always ask, whatever the settings say, and the dialog has no “Don’t ask again”. You type the database name (or the connection’s name, if it names no database) before you can run the statement.
• Read-only to start. When you tag a connection as production, Read-only is checked for you. You can uncheck it.
• Markers combine color, text and an icon:
  • a banner at the top of each console: ⚠ PRODUCTION · <connection>, with the read-only protection when it applies
  • a banner in each result’s header
  • PRODUCTION in the status bar
  • the window title: DataKlin — <connection> [PRODUCTION] while a production console is active
• Weaker TLS needs confirmation: see TLS and certificates.

Connections tagged Staging get the console and result banners too, in a less urgent color.