Metadata-Version: 2.4
Name: dcm-processor-db-provider
Version: 0.0.1
Summary: A Command line tool for the dicom processor library
Home-page: https://github.com/giesekow/dcm-processor-db-provider
Author: Giles Tetteh
Author-email: giles.tetteh@tum.de
Keywords: orthanc,dicom,worker,processor,translation,medical
Classifier: Programming Language :: Python :: 3
Classifier: License :: OSI Approved :: MIT License
Classifier: Operating System :: OS Independent
Description-Content-Type: text/markdown
License-File: LICENSE
Requires-Dist: dcm-processor-utils==0.0.1
Requires-Dist: pydicom==3.0.1
Requires-Dist: pymongo==4.16.0
Requires-Dist: python-magic==0.4.27
Requires-Dist: requests==2.32.4
Requires-Dist: uuid==1.30
Requires-Dist: nested-property==1.1.5
Dynamic: license-file

# dcm-processor-db-provider

`dcm-processor-db-provider` is the persistence layer for the dcm-processor platform.

It defines the storage-facing API used by the other modules and currently provides a MongoDB-backed implementation for:

- metadata storage
- job queue storage
- session storage
- GridFS-backed file storage
- application settings

## Role In The Bigger Picture

This module is the shared state layer for the platform.

Nearly every other module depends on it:

- `dcm-processor-cli` uses it for app config, services, workers, peers, and nodes
- `dcm-processor-dicom-server` uses it to persist received DICOM data
- `dcm-processor-job-scheduler` uses it to discover work and create queued jobs
- `dcm-processor-worker` uses it to fetch service and worker artifacts and job records
- `dcm-processor-service` uses it indirectly for session data, files, and peer/session lookups

If the CLI is the front door, this module is the system record.

## Main Responsibilities

### 1. Database Abstraction

The package exposes `DBManager`, which acts as the common API used across the platform.

Its job is to hide provider-specific details behind a shared interface for:

- services
- workers
- jobs
- sessions
- peers
- nodes
- patients, studies, series, and instances
- app settings
- component files and session files

### 2. File Storage

This package stores binary artifacts such as:

- service modules
- service registry modules
- worker support files
- uploaded DICOM objects
- session files

That makes it the bridge between metadata records and binary package/data payloads.

### 3. Job Queue Persistence

The job scheduler writes queued jobs through this module, and workers read them back through the same API.

This includes:

- creating jobs
- resolving session ids from jobs
- storing and reading session data and files
- cleaning up session data

### 4. DICOM Metadata Persistence

The DICOM server stores received instance data through this package, and the DB manager builds the patient/study/series structure around those objects.

## Key Internal Areas

- `dcm_processor_db_provider/manager.py`
  - high-level manager used by the rest of the system
- `dcm_processor_db_provider/base.py`
  - abstract provider interface
- `dcm_processor_db_provider/mongo.py`
  - MongoDB/GridFS implementation
- `dcm_processor_db_provider/conversion.py`
  - data conversion helpers

## Data Domains Managed Here

This module manages the persistence contract for:

- application settings
- DICOM peers and nodes
- services and workers
- queued jobs
- sessions
- session files and key/value session data
- DICOM files and derived patient/study/series metadata

## What This Module Is Not

This package is not:

- the command-line interface
- the scheduler logic
- the DICOM network server
- the worker runtime itself

It stores and retrieves the system state those modules operate on.

## Summary

Use this module when you need the system’s durable state.

It is the storage contract that lets the CLI, scheduler, DICOM server, worker runtime, and service helpers all speak the same persistence language.
