medien

This page was automatically generated from the database schema dump and may be incomplete or incorrect.

Master-data table of storage media. Each row represents a physical or logical volume (disk, cloud bucket, optical medium). Referenced by objectX.medium_doc and objectX.medium_dia.

Besides the archive media this table also holds the system media the server uses for working files and note files. Each system medium has a state of its own and a directory of its own in path; a real archive or removable medium has neither.

id name state Row in path Use

4

WORK

3

flag = 0

working files, referenced by objectX.medium_doc

5

NOTE

4

flag = 2

note text files, referenced by remarks.medium

assigned in sequence

freely chosen

0 (free)

none

real archive or removable medium

A real excerpt shows how sparsely the system media are filled in: apart from id, name, server_id and state nothing is set, while the real medium carries a set, an order and sizes.

id      name         batch  server_id  set_id  state  medorder  medsize  written  mirror_id  autolocked  cluster_size  medsize2
4       WORK         NULL   3          NULL    3      NULL      NULL     NULL     NULL       NULL        NULL          NULL
5       NOTE         NULL   3          NULL    4      NULL      NULL     NULL     NULL       NULL        NULL          NULL
147927  blub0001bla  NULL   3          147918  0      1         650      0        0          NULL        640           0

The archive media of the server group’s own are held in this table as well. Archiving into an external system is not covered: no row is created here for it.

The IDs come from the same global running sequence as all other object IDs (see osnextindex). 4 and 5 are therefore the result of the order during system setup and not guaranteed constants; resolve the assignment through name, not through the number.

Every medium column in the application carries values from this table and follows the actual storage location: a document on an archive medium carries that medium’s ID instead of the one for WORK. The separation holds strictly in the other direction too — on the system measured no document sat on NOTE and no note on WORK. There are no foreign keys, so the database does not enforce the assignment. Measured against enaio® server 12.0.

The point of this indirection through a medium ID is multi-server-group capability: installing a server group creates a WORK and a NOTE medium with IDs of their own and one row each in path. Through medien.server_id a server uses the medium ID to recognise whether a file belongs to its own server group.

With several server groups and note storage in the file system, the NOTE directories of the groups have to be kept in sync, otherwise one group cannot find another group’s note files.

1. Columns

Name Type Length Description

id

int

—

Medium ID (primary key).

name

nvarchar

100

Display name / label of the medium.

batch

int

—

Batch ID (write operation).

server_id

int

—

ID of the server group, not of the individual server. Through it a server uses the medium ID to tell whether an object belongs to its own server group or to another one.

set_id

int

—

Set identifier (logical grouping).

state

int

—

Kind of medium: 0 = free, 1 = locked, 2 = no meaning, 3 = WORK area, 4 = NOTE area. The values 3 and 4 therefore mark the two system media.

medorder

int

—

Sort / order index.

medsize

int

—

Medium size (bytes — see also medsize2).

written

int

—

Bytes written / fill level.

mirror_id

int

—

ID of a mirrored medium (for mirror groups).

autolocked

int

—

Auto-lock flag.

cluster_size

int

—

Cluster size.

medsize2

int

—

Medium size (second value; extends medsize for large volumes).

2. Related tables

  • medrel — relations to media sets.

  • archex — mapping of document types to servers for archiving.

  • remarks — points at the NOTE system medium through medium.

  • path — directories of the system media.