gmakstutis/LightRAG
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LightRAG/logs/2024-12-05-01-30-beastmode-audit-log.md
Raphaël MANSUY 730c406749 feat: Implement multi-tenant support across graph and query routes 
- Enhanced graph_routes.py and query_routes.py to support multi-tenant architecture by introducing tenant-specific RAG instances.
- Updated create_graph_routes and create_query_routes functions to accept rag_manager for tenant management.
- Added get_tenant_rag dependency to all relevant endpoints to ensure tenant context is utilized for operations.
- Modified Vite configuration to include comprehensive API proxy rules for seamless interaction with backend services.
- Implemented cascade delete functionality in tenant_service.py for tenant and knowledge base deletions.
- Added detailed logging and error handling for tenant operations.
- Created audit logs documenting the multi-tenant implementation process and decisions made.
2025-12-05 00:04:29 +08:00

1.8 KiB
Raw Blame History

Task Log: Multi-Tenant vs Workspace Audit

Date: 2024-12-05 01:30 UTC
Mode: Beastmode
Task: Audit Multi-Tenant vs Workspace redundancy

Actions

  1. Fetched upstream LightRAG README to understand workspace feature
  2. Analyzed core lightrag/lightrag.py workspace parameter usage
  3. Analyzed lightrag/kg/postgres_impl.py for table schemas with workspace
  4. Analyzed lightrag/services/tenant_service.py for tenant management
  5. Analyzed lightrag/tenant_rag_manager.py for RAG instance management
  6. Analyzed lightrag/models/tenant.py for data models
  7. Analyzed lightrag/security.py for workspace/tenant validation
  8. Analyzed starter/init-postgres.sql for database schema
  9. Used sequential thinking to compare architectures
  10. Created comprehensive audit report: docs/0009-multi-tenant-vs-workspace-audit.md
  11. Implemented cascade delete for delete_knowledge_base() method
  12. Implemented cascade delete for delete_tenant() method
  13. Fixed linting issues with ruff

Decisions

  • Tenant feature is NOT redundant - it's a proper application layer on top of workspace
  • Workspace provides storage-level isolation (HOW data is separated)
  • Tenant provides application-level multi-tenancy (WHO can access WHAT)
  • Composite workspace format {tenant_id}:{kb_id} bridges the two layers

Next Steps

  1. Add unit tests for cascade delete functionality
  2. Consider adding DB triggers for referential integrity
  3. Update user-facing documentation with workspace naming convention

Lessons/Insights

  • LightRAG uses a layered architecture that correctly separates storage isolation from access control
  • Generated columns in PostgreSQL allow querying by tenant/KB without schema changes
  • The TenantRAGManager acts as a bridge, creating composite workspace identifiers