Edition Strategy¶

Overview¶

During online updates and installations, modifying data in existing tables poses a significant risk. The core challenge is that tables and their data are shared across all editions in a non-editionable manner. This means that any modifications during installation could cause the current system to encounter unexpected data states, potentially leading to errors or unintended behavior.

The Challenge¶

When performing online updates, we face several challenges: - Tables and data are shared across all editions - DML operations (INSERT, UPDATE, DELETE) need isolation from the live system - Changes in one edition shouldn't affect users in another edition

Solutions¶

IFS provides two robust solutions to handle these scenarios:

1. Edition Column Strategy (datarecord)¶

This solution adds edition-tracking columns to tables to manage data visibility across editions. Key features: - Adds insert_edition$ and delete_edition$ columns - Implements Row-Level Security (RLS) policies - Perfect for adding new records and deleting records without affecting the live system

Learn more about Edition Column Strategy →

2. Staging Solution (emptytable/clonetable)¶

This approach creates isolated staging tables for data modifications during updates. It offers two variants: - emptytable: Creates an empty clone of the original table - clonetable: Creates a populated clone of the original table

Learn more about Staging Solution →

Choosing the Right Strategy¶

Consider these factors when selecting a strategy:

Factor	Edition Column	Staging Solution
Data Volume	Large tables	Small Tables
Modification Type	Inserts/Deletes	Any DML Operation
Performance Impact	Minimal	Depends on Clone Size
Live System Impact	Open For Writes	Blocked Writes

Best Practices¶

Always use the appropriate EditionStrategy annotation
Enable the strategy before performing any data modifications
Wrap modifications in patch registration blocks
Test the solution thoroughly in a staging environment
Document any table-specific considerations