Database Tab (DICONDE Component/Study/Image)

The solution currently has no database, YAML configuration, or DICONDE models: Shell contains only the Viewer tab (ShellView.xaml), and images live in memory (ViewerViewModel.cs, Image.cs). First iteration: catalog + search + open in Viewer + store TIFF files. There is no tag form during acquisition: tag dialogs exist only on the Database tab.

Component is a tag level in YAML and the UI, not a database table. The schema contains Study, Image, StudyTag, and ImageTag. Tags from tags.component and tags.study are stored as StudyTag rows; tags.image tags are stored as ImageTag rows.

Therefore, multiple Studies do not share a single Component record. “New Study for Component” copies the component tags from the selected row to the new Study. Editing ComponentName on one Study does not change the others.

Tags: Two EAV Tables, Not JSON

YAML is the source of truth for the set of tags. The database has no fixed set of columns.

Recommendation: StudyTag and ImageTag, not a shared table and not a JSON column.

• Strong FK: a study tag cannot accidentally reference an image and vice versa; cascade deletion works without a nullable discriminator.
• Worklist filters use only keys with grid: true: string → LIKE, date / time / integer / number → range. There is no global search field. Filters exclude dialog-only and internal tags.
• YAML can be changed without migrations.

Store values as strings (TEXT). Do not duplicate the catalog in the database. Keys that are no longer present in YAML do not appear in the grid, dialogs, or filters (orphaned values after a catalog change remain in the database, but the worklist does not show them).

The tag level (component/study/image) is not stored in the database; it is defined by the YAML list in which the key appears. StudyTag rows whose keys come from tags.component and tags.study differ only by Key.

Uniqueness: (StudyId, Key) and (ImageId, Key).

Dates (type: date): canonical database format is yyyyMMdd (same as DICONDE DA, without hyphens). Lexicographic comparison matches chronological order. The UI uses the local format and converts back to yyyyMMdd when saving. Filter: two dates, “from/to”.

Time (type: time): canonical database format is HHmmss (24-hour; in .NET use HH, not hh, which is 12-hour). String comparison gives the correct order within a day. Do not combine this with date: StudyDate / StudyTime are separate tags, not a single datetime. Filter: two time values, “from / to”.

Integers (type: integer): canonical database value has no fractional part (42). Optional min / max in YAML map to NumberBox.Minimum / Maximum in the dialog and filter. If omitted in YAML, there is no limit. Filter: range using CAST(Value AS INTEGER).

Numbers (type: number): use invariant culture. decimals in YAML is required (number of digits after the decimal point: widget, grid, and canonical database value). Missing decimals is a catalog loading error; do not default to 2. min / max work the same way as for integer. Use integer for kV and counters, not this type.

Editors in the dialog (based on type, not a generic TextBox). The UI stack is WPF-UI (VizRay.csproj); Extended WPF Toolkit is not used in the project:

• string — TextBox (WPF-UI / standard)
• date — ui:CalendarDatePicker