drawing_versions
This table stores the individual uploaded versions of a drawing set. Each version corresponds to a specific uploaded revision and its OCR/review lifecycle.
Purpose
The purpose of this table is to capture the versioned history of a drawing set and represent each uploaded revision as its own reviewable record.
What this table does
- Represents one uploaded revision of a drawing set
- Tracks OCR processing and review state
- Stores version-specific dates, revision labels, and extraction metadata
- Acts as the parent of the final confirmed sheets for that version
Why this table is defined
A drawing set may change many times. Users need version history, and the application needs to preserve each upload’s independent OCR and sheet-confirmation result.
Columns
| Column | Type | Required | Description | Example |
|---|---|---|---|---|
id |
uuid | Yes | Primary key for the version record | dver_003 |
tenant_id |
uuid | Yes | Tenant owning the version | tenant_001 |
drawing_set_id |
uuid | Yes | Drawing set this version belongs to | dset_001 |
version_no |
int | Yes | Sequential version number | 3 |
revision_label |
text | No | Human-readable revision tag | Rev 3 |
status |
text | Yes | Lifecycle status of this version | review_required |
uploaded_by |
uuid | No | User who uploaded the version | user_123 |
uploaded_at |
timestamptz | Yes | Upload timestamp | 2026-04-11 10:12:00+00 |
drawing_date |
date | No | Date shown on the drawing revision | 2026-04-01 |
received_date |
date | No | Date the revision was received | 2026-04-03 |
ocr_provider |
text | No | OCR/AI provider used | gemini |
ocr_summary |
jsonb | Yes | Summary of OCR processing output | {"detected_sheets": 48} |
review_required |
boolean | Yes | Whether user review is needed before finalization | true |
finalized_at |
timestamptz | No | When the version was finalized | 2026-04-11 10:40:00+00 |
Relationships
- drawing_set_id → drawing_sets.id
- id is referenced by drawing_sheets.drawing_version_id
How it is used
- Created whenever a new revision is uploaded
- Updated by OCR and sheet-confirmation workers/processes
- Displayed in drawing version history
- Used to mark which version is current on the parent set
Access and security
- Version creation should be limited to authorized project users
- Previous versions should remain viewable but read-only where required
- Do not mutate finalized sheet content in ways that break auditability
Example scenarios
Scenario 1: OCR processing
A newly uploaded version sits in processing while OCR runs.
Scenario 2: Review workflow
After OCR, the version moves to review_required and users confirm sheet names.
Scenario 3: Finalization
Once review is complete, the version is finalized and may become current.
Notes and assumptions
- Statuses should mirror the actual pipeline state closely
- Each version should preserve its own OCR output and review history
- Annotation carryover rules should be handled carefully at higher layers