Welcome to Open Legal Data Platform’s documentation!

OLDP is a web application, written in Python 3.5 and based on the Django web framework, It is used for processing legal text and providing a REST-API and Elasticsearch-based search engine. OLDP is being develop by the non-profit initiative Open Legal Data with the goal of building an Open Data platform for legal documents (mainly court decisions and laws). The platform makes legal information freely accessible for the general public and especially third-party apps.

Contents:

• Getting started
  • Install dependencies
  • Run tests
  • Docker
  • Run server manually
• Testing
  • Fixtures
  • App tests
  • Browser Tests
  • Coverage Integration
• API
  • Base URL
  • Authentication
  • Permission System
  • Throttle Rates
  • API Endpoints
  • Pagination
  • Search
  • My Resources (/me/)
  • Creating and Updating Resources
  • Error Handling
  • Response Formats
  • Best Practices
  • Examples
  • Data Dumps and Bulk Downloads
• API Swagger
  • Clients generator
  • Other notes
• Case Creation API
  • Overview
  • Endpoint
  • Authentication
  • Request Format
  • Response Format
  • Court Name Resolution
  • Source Resolution
  • Reference Extraction
  • Validation Settings
  • API Token Tracking
  • Approval Workflow
  • Examples
  • Best Practices
• Django - Notes & Useful commands
  • Django basics
  • Custom commands
  • Search
  • Tests
  • Cache
  • Flatpages
  • Sitemaps
  • Generate UML diagram from models
• Development
  • Useful links
  • Write a custom processing step
• Processing
  • Django Admin
  • Available content processors
• Elasticsearch
  • Propagate database entries to search index
  • Queries
  • Load Index Mappings
• Database
  • Schema
  • Set encoding
• Production
  • Deployment
  • Commands
  • Clean up database
  • Helper commands for migration
• Docker & Podman
  • Getting started
  • Common issues
  • Additional notes
• Performance Optimization Audit
  • Profiling Report
  • 1. Database Query Issues (HIGH)
  • 2. Caching Gaps (HIGH)
  • 3. Elasticsearch / Search (MEDIUM)
  • 4. Middleware & HTTP (MEDIUM)
  • 5. Context Processor Overhead (LOW)
  • 6. SQL Injection Risk + Performance (LOW)
  • 7. Deployment / Infrastructure Recommendations
  • Summary — Priority Matrix
• Performance Profiling Methodology and Findings (2026-02-22)
  • Scope
  • Environment and Tooling
  • Important Runtime Setup Notes
  • Methodology
  • Findings
  • A. DevConfiguration profiling (with real cache behavior)
  • B. Case Detail (/case/foo-case) Deep Dive and Optimizations
  • C. Cache Correctness Fixes Verified During Profiling
  • D. Remaining Bottlenecks / Next Targets
  • E. Continued Profiling: Search and Law Pages (same temp DB, DevConfiguration)
  • F. New Bottleneck Identified: Cold /law/gg/ Page (LawBook.sections N+1)
  • G. Smaller Cold-Path Pattern: Duplicate get_revision_dates() Queries on Law Pages
  • H. Implemented Follow-up Fix for Law Pages and Re-Profiling Results
  • I. Final Consolidated Post-Fix Sweep (API + Frontend + Laws + Search)
  • J. Profiling Still Worth Doing (Not Completed in This Session)
  • K. Phase 1 (Conservative) Implementation Update: Anonymous Search/API Speed
  • L. Phase 2 (Conservative) Implementation Update: Public Docs/Autocomplete + Small View Wins
  • Caveats
  • Files Changed During This Profiling Work (Relevant to Findings)
• Performance Optimization Beyond Django (Gunicorn, Nginx, MariaDB, Elasticsearch, Redis)
  • 1. Optimization Priorities (Recommended Order)
  • 2. Gunicorn (App Server)
  • 3. Nginx (Reverse Proxy, Compression, Static Files)
  • 4. MariaDB (Database)
  • 5. Elasticsearch (Search Backend)
  • 6. Redis (Cache Backend)
  • 7. Docker Compose Example (Production-Like Baseline)
  • 8. Docker Compose Tuning Notes
  • 9. Observability and Load Testing (Recommended)
  • 10. Practical Rollout Strategy
  • 11. Checklist (Quick Reference)

Indices and tables

• Index

• Module Index

• Search Page