Skip to main content

Database Versioning Guide

CONA implements four different tracking approaches for database versioning, each designed for specific use cases. This guide provides detailed implementation guidelines for each approach.

1. Audit Trail Versioning

Used for: entities, addresses, organization details, payment methods

Implementation

The Audit Trail approach creates a complete history of all changes to a record by maintaining a parent-child relationship with a root record. Each update creates a new record while preserving the history through these relationships.

Implementation Pattern

Query Patterns

2. Activity Log Tracking

Used for: product_variants, documents, inventory adjustments, price changes

Implementation

Activity Log Tracking records specific notable activities rather than capturing every change to a record. In CONA, this is implemented using a centralized activity_logs table that tracks changes across different entity types.

Implementation Pattern

Query Patterns

3. Simple Update

Used for: sales_channels, locations, tax rates, shipping methods

Implementation

Simple Update tracking only maintains the current state with basic timestamp tracking.

Implementation Pattern

Query Patterns

4. Soft Delete with New Record

Used for: contacts, email_addresses, phone_numbers, shipping addresses

Implementation

This approach maintains historical records while preserving data integrity by marking records as deleted rather than removing them from the database.

Implementation Pattern

Query Patterns

When to Use Each Approach

Audit Trail Versioning

Best for: Core business entities where all changes must be tracked for compliance or auditing purposes. Characteristics:
  • Complete change history is critical
  • Legal or compliance requirements
  • Need to restore to any previous state
  • Changes are relatively infrequent

Activity Log Tracking

Best for: Records where specific activities are more important than tracking every change. Characteristics:
  • Domain-specific activities need tracking
  • More concerned with what happened than complete change history
  • Frequent minor changes that don’t need full history
  • Need to track who performed specific actions

Simple Update

Best for: Configuration or reference data where only the current state matters. Characteristics:
  • Only current state is relevant
  • Change history is not needed for business operations
  • Support data rather than core business entities
  • Frequent changes where history is not valuable

Soft Delete with New Record

Best for: Records where historical values may still be referenced by other records. Characteristics:
  • Need to maintain referential integrity with historical data
  • Both current and previous versions may be needed
  • Changes create effectively new entities
  • Changes are infrequent but meaningful