a8f5c9bd33
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) |
||
|---|---|---|
| .. | ||
| api | ||
| evaluation | ||
| kg | ||
| llm | ||
| tools | ||
| __init__.py | ||
| base.py | ||
| constants.py | ||
| exceptions.py | ||
| lightrag.py | ||
| namespace.py | ||
| operate.py | ||
| prompt.py | ||
| rerank.py | ||
| types.py | ||
| utils.py | ||
| utils_graph.py | ||