History

4D was originally developed under the name "Silver Surfer" in the 1980s as a DBMS for the Macintosh platform.

Checkpoints[06][07][08]

Every modification to the data file since the last backup is recorded in the associated log file. If the database file is corrupted, 4D will restore the most recent backup and replay the changes in the log. When a new backup is created, the log file is cleared. Backups can be triggered manually or on a schedule. The database cannot be edited while a backup is running.

Compression[09][10]

4D Web Server supports using gzip compression when communicating with clients. Gzip compression can also be used to shrink BLOB objects stored in the database. The 4D documentation does not mention support for any other types of compression.

Concurrency Control[11][12][13]

4D requires users to explicitly lock/unlock records and avoid deadlocks. For every user/process, each table in the database is given a read-only or read/write status. If a table is in the read-only state for a given user, all existing records loaded from the table are considered locked and cannot be modified. Any user can append new records to a table, even if it is read-only. If a table is in the read/write state, records will load as unlocked for the first user to load them. To modify a record that is already locked, a user can repeatedly load the record until it unlocks. A user unloads a record to make it available again to other users/processes.

A user can change a table from read-only to read/write or back at any time, but this only affects future load requests made by that user. If a read/write command is executed on a locked record, the command will either be ignored, display an error, or skip the record (if the command targets multiple records). Skipped records are added to the LockedSet of the requesting process to alert it of the error.

Queries can be grouped into transactions to ensure that changes occur atomically, but there is no deadlock prevention/detection. While a transaction is running, changes are saved into a temporary buffer and any modified records are locked.

Data Model[14]

4D uses a standard relational database structure with tables, fields, and relations.

Foreign Keys[15]

4D supports One-to-One, Many-to-One, and Many-to-Many relations between tables. Relations are classified as either automatic or manual. Automatic relations cause foreign records to be loaded with records that reference them, while manual relations do not. Automatic relations should avoid cyclic references.

Hardware Acceleration[16]

The 4D documentation makes no mention of hardware acceleration.

Indexes[17]

Indices can use a B+Tree or clustered B+Tree. 4D supports composite indices (indices on pairs of values). It also supports keyword indices (indices mapping individual words to records containing them).

Isolation Levels[18][13]

Transactions lock records they modify or create, preventing other transactions from interfering with them. Unrepeatable reads may occur since transactions do not lock records they read. Table entries can be added while a transaction is running, creating invalid aggregation results (phantom problem). Transactions store all modifications in a temporary buffer, so uncommitted data can't affect other transactions.

Isolations levels for 4D transactions are not mentioned in the product documentation, but the behavior is consistent with the Read Committed isolation level.

Logging[19][20]

When a new data file is created, 4D automatically generates a log file for it with the ".journal" extension. The log file contains a record of all modifications since the last database backup. Entries describe the change that was performed as well as the user and time of the modification. The log also records when a user opens/closes the database.

Parallel Execution[21]

4D does not automatically utilize parallelism, but users can manually exploit parallelism by running multiple processes. Concurrency control and record locking for multiple 4D processes is handled similarly to multi-user scenarios.

Query Compilation[22]

The 4D language can be either interpreted or compiled. By default, an interpreter is used. A built-in compiler can convert the database application into machine code to increase performance.

Query Interface[23][24]

4D provides a graphical interface for managing data in a 4D database. Developers can customize the interface using the proprietary 4D programming language to provide additional buttons/forms for data manipulation. The language has syntax for control flow, variable creation, and database queries.

4D includes a SQL engine and the language supports inline SQL queries, though any SQL functionality can be replicated using the 4D language.

Storage Architecture[06]

4D database files are stored on disk. An in-memory cache is used to improve performance, but transactions are immediately written to the on-disk log file when they are committed.

Storage Model[25]

A 4D database consists of: - A structure file describing the database schema - A data file (records stored in a row store format) - A log file for data recovery - A Resource folder containing images/assets for any custom UI - A preferences folder