# pouchdb

## Learning Path

[View on GitHub](https://github.com/apache/pouchdb "View on GitHub")

### Welcome to pouchdb

Your guide to understanding the codebase

### Change Guide

### 5 levels

### 15 learning units

- **Orchestration & APIs**  
  Pipelines, workflows, public interfaces • 3 units
- **Document Operations & Data Model**  
  API · 7
- **PouchDB Core Architecture**  
  Architecture · 2
- **Essential Patterns & Utilities**  
  Patterns · 4
- **Core Logic & Data**  
  Business rules, schemas, models • 3 units
- **Changes Feed & Query System**  
  API · 7
- **Integration Layer**  
  Integration · 12
- **Replication & Sync Protocol**  
  Workflow · 6
- **Interaction & Integration**  
  UI components, external connectors • 2 units
- **Comprehensive Test Architecture**  
  Testing · 5
- **Storage & Migration Systems**  
  Testing · 7
- **Cross-Cutting Concerns**  
  Auth, logging, config, testing • 2 units
- **Advanced Concurrency & Documentation**  
  Concurrency · 27
- **Performance & Reliability Testing**  
  Testing · 15
- **Edge Cases & Resilience**  
  Error handling, fault tolerance • 2 units
- **Additional Data Model Patterns**  
  Data Model · 2
- **Additional Error Handling Patterns**  
  Error Handling

### Test Your Knowledge  
24 questions across all levels

### Progress
0/24 answered

### Hands-On Assignment

2-3 hours

### Your Challenge

Implement a document versioning plugin that maintains a complete history of document changes in a separate collection. When a document is updated or deleted, your plugin should automatically store the previous version in a `{dbname}_history` database with metadata about the change (timestamp, operation type, revision). This will allow developers to query historical versions and potentially restore previous states.

### Starting Points

- `CONTRIBUTING.md:1-72`  
 Understand the project structure and how to set up your development environment for building and testing plugins

- `bin/build-module.js:1-66`  
 Study how PouchDB modules are built and packaged - your plugin will follow similar patterns

- `bin/build-node.sh:1-7`  
 See how the build process works for Node.js modules

### Success Criteria

- Plugin successfully intercepts put, post, and remove operations without breaking existing functionality
- Previous document versions are stored in a separate `{dbname}_history` database with proper metadata
- A `getHistory(docId)` method returns all historical versions of a document in chronological order
- A `restoreVersion(docId, timestamp)` method can restore a document to a previous state
- The plugin can be built using the existing build system (npm run build works)
- History entries include: original document content, revision, timestamp, and operation type
- Plugin handles edge cases: first document creation, missing history db, and deleted documents

### Hints

- (click to reveal)
- **Hint 1**: Understanding PouchDB's plugin architecture conceptual
- **Hint 2**: Accessing document state before changes implementation
- **Hint 3**: Managing the history database implementation
- **Hint 4**: Plugin structure and API code location
- **Hint 5**: Handling edge cases conceptual

### Prerequisites

- JavaScript promises and async/await
- PouchDB basic operations (put, get, remove)
- Plugin architecture patterns
- Document revision system basics