Why this change is needed:
In multi-tenant deployments, when workspace A migrates first (creating
the new model-suffixed table), subsequent workspace B initialization
enters Case 1 (both tables exist). The original Case 1 logic only
checked if the legacy table was empty globally, without checking if
the current workspace had unmigrated data. This caused workspace B's
data to remain in the legacy table while the application queried the
new table, resulting in data loss for workspace B.
How it solves the problem:
1. Extracted migration logic into _pg_migrate_workspace_data() helper
function to avoid code duplication
2. Modified Case 1 to check if current workspace has data in legacy
table and migrate it if found
3. Both Case 1 and Case 4 now use the same migration helper, ensuring
consistent behavior
4. After migration, only delete the current workspace's data from
legacy table, preserving other workspaces' data
Impact:
- Prevents data loss in multi-tenant PostgreSQL deployments
- Maintains backward compatibility with single-tenant setups
- Reduces code duplication between Case 1 and Case 4
Testing:
All PostgreSQL migration tests pass (8/8)
a8f5c9bd33