...
| Kolumnnamn | Null | Primär- nyckel | Del av logisk- nyckel | Typ och Längd |
|---|---|---|---|---|
| id | Nej | X | Varchar(64) | |
registered_resident_identificationid | Nej | X | Varchar(32) | |
service_domain | Nej | X | Varchar(255) | |
categorization | Nej | X | Varchar(255) | |
logical_address | Nej | X | Varchar(64) | |
business_object_instance_identifierid | Nej | X | Varchar(128) | |
source_system | Nej | X | Varchar(64) | |
data_controller | Nej | X | Varchar(64) | |
owner | Nej | X | Varchar(64) | |
clinical_process_interest_id | Nej | X | Varchar(128) | |
creation_time | Nej | Timestamp | ||
update_time | Ja | Timestamp | ||
most_recent_content | Ja | Timestamp |
...
För sökningar används springs JPA repository interface, där sökningar definieras antingen med namnkonvention eller med SQL (JPQL) satser. För närvarande krävs fälten registered_resident_id och service_domain för sökningar i enlighet med findContent meddelandet, och detta skiljer sig från den nuvarande specifikationen (RC10).
Om tidstämpel är angiven (most_recent_content) så returneras alla poster som har ett värde som är större eller lika med detta för övriga fält måste värdena vara exakt likadana.
Transaktioner
Precis som förespråkas i tjänstekontraktsbeskrivningen så krävs ingen särskild transaktionskonsistens när man läser data, dvs. man tillåter så kallade "dirty reads" om nu den underliggande databasen tillåter detta. Självfallet måste alla skrivningar hanteras på ett atomärt och konsistent sätt, även om man tillåter sk. "dirty reads".
...