drawing_sets
This table represents a logical drawing set within a project, such as an architectural or structural plan set. It is the parent record for drawing versions and organizes a group of related sheets over time.
Purpose
The purpose of this table is to provide a stable logical container for drawings that may have multiple uploaded versions over time.
What this table does
- Represents a named drawing set within a project
- Groups versions of the same set together
- Provides project-level organization for drawing workflows
- Acts as the root object shown in the drawings UI
Why this table is defined
Drawings need version history, review flows, and user navigation at the set level. A drawing set is more stable than any one uploaded PDF, so it deserves its own table.
Columns
| Column | Type | Required | Description | Example |
|---|---|---|---|---|
id |
uuid | Yes | Primary key for the drawing set | dset_001 |
tenant_id |
uuid | Yes | Tenant owning the drawing set | tenant_001 |
project_id |
uuid | Yes | Project the set belongs to | project_phoenix |
name |
text | Yes | Display name of the set | Architectural Rev 3 |
status |
text | Yes | Current state of the set lifecycle | processing |
current_version_id |
uuid | No | Current active version for the set | dver_003 |
default_drawing_date |
date | No | Default drawing date used during upload/review | 2026-04-01 |
default_received_date |
date | No | Default received date used during upload/review | 2026-04-03 |
default_revision |
text | No | Default revision label | Rev 3 |
language_code |
text | No | Language hint for OCR or parsing | en |
created_by |
uuid | No | User who created/uploaded the set | user_123 |
created_at |
timestamptz | Yes | Creation timestamp | 2026-04-11 10:10:00+00 |
updated_at |
timestamptz | Yes | Last update timestamp | 2026-04-11 10:20:00+00 |
Relationships
- project_id → projects.id
- current_version_id → drawing_versions.id
- id is referenced by drawing_versions.drawing_set_id
How it is used
- Shown in project drawings list/grid views
- Used to organize version history for a set of sheets
- Used as the top-level object when uploading revisions
Access and security
- Project access rules must apply
- Only authorized users should create new versions
- Changes to current version should be auditable
Example scenarios
Scenario 1: New set upload
A user uploads a new architectural drawing package, creating a new drawing set.
Scenario 2: Revision added
A later upload becomes a new drawing version under the same set.
Scenario 3: Current version switch
The newest approved version becomes the set’s current version.
Notes and assumptions
- A drawing set is a logical grouping, not necessarily one uploaded file
- Statuses should reflect processing and review lifecycle clearly
- The current version should be updated only after confirmation rules are satisfied