Jeg tror testen kan fjernes og forståelsen er ganske greit gjennomgått i din forklaring.
Thomas ________________________________ Fra: Petter Reinholdtsen pere@hungry.com Sendt: fredag 4. september 2026 15:48 Til: nikita-noark@nuug.no nikita-noark@nuug.no Emne: Hva er utfordringen med arkivdeler og klassifikasjonssystemer?
Jeg kom over denne utkoblede testen i kodebasen til Nikita:
/** * Verifies behaviour when a Series that already has a * ClassificationSystem is patched with a different * ClassificationSystem. * * <p><b>Design question (unresolved):</b> Should nikita reject this * request with a 4xx because the Series already has a * ClassificationSystem (forcing the client to explicitly * disassociate first), or should it silently replace the existing * association? The current implementation adds the new * ClassificationSystem without removing the old one, which is * incorrect regardless of which policy is chosen.</p> * * <p>Before enabling this test, add {@code * SECOND_CLASSIFICATION_SYSTEM_SYSTEM_ID} to {@code * basic_structure.sql} as a second ClassificationSystem not yet * associated with {@code SERIES_SYSTEM_ID}.</p> * * @throws Exception if the HTTP interaction fails */ @Disabled("Unresolved design: reject-if-exists vs replace; implementation broken either way") @Test @WithMockNikitaUser public void associateSeriesWithDifferentClassificationSystem_thenOk() throws Exception { String seriesUrl = SLASH + HREF_BASE_SERIES + SLASH + SERIES_SYSTEM_ID; String patchUrl = seriesUrl + SLASH + NEW_CLASSIFICATION_SYSTEM;
String classificationSystemHref = getSelfHref(SLASH + HREF_BASE_CLASSIFICATION_SYSTEM + SLASH + SECOND_CLASSIFICATION_SYSTEM_SYSTEM_ID);
String payload = String.format( "{"%s": {"href": "%s"}}", REL_FONDS_STRUCTURE_NEW_CLASSIFICATION_SYSTEM, classificationSystemHref);
String etag = getETag(seriesUrl);
mockMvc.perform(MockMvcRequestBuilders .patch(patchUrl) .header("If-Match", etag) .accept(NOARK5_V5_CONTENT_TYPE_JSON) .contentType(NOARK5_V5_CONTENT_TYPE_JSON) .content(payload)) .andExpect(status().isOk()) .andExpect(jsonPath("$." + SYSTEM_ID).exists()); }
Merk, jeg mistenker testen bruker feil relasjonsnøkkel i PATCH-operasjonen og burde vært REL_CASE_HANDLING_SECONDARY_CLASSIFICATION eller lignende, men det er på siden av mitt spørsmål.
Antagelsen i kommentaren på toppen ser ut til å være at en arkivdel kun kan ha et klassifikasjonssystem, og jeg klarer ikke finne en kilde til den antagelsen. Noen som vet hvor den kommer fra?
Så vidt jeg kan se er følgende struktur fullt ut akseptabel i Noark 5:
arkiv - arkivdel - klassifikasjonssystem 1 - klasse 1 - klassifikasjonssystem 2 - klasse 2
Dagens implementasjon i Nikita lar en både opprette klassifikasjonssystem to med POST til ny-klassifikasjonssystem under aktuell arkivdel, men også flytte et klassifikasjonssystem fra en arkivdel til en annen. Gjeldende beskrankninger har altså intet problem med to klassifikasjonssystem på samme nivå under samme arkivdel. Er det i strid med N5v5?
Det er altså i dag mulig å gå fra denne strukturen:
arkiv - arkivdel 1 - klassifikasjonssystem 1 - arkivdel 2 - klassifikasjonssystem 2
til denne strukuren ved en enkel PATCH av klassifikasjonssystem 2 med aktuell _links-peker satt til arkivdel 1:
arkiv - arkivdel 1 - klassifikasjonssystem 1 - klassifikasjonssystem 2 - arkivdel 2
Jeg trodde dette var greit, men kommentaren i testen gjør meg usikker, og jeg klarer altså ikke finne forklaring ved å titte i N5v5.
Eller er dette en fullstendig misforståelse, og handler det i stedet om hvordan sekundærklassifikasjon skal håndtes på mappe og registreringsnivå, og har intet med arkivdel (series) å gjøre?
Svært forvirret over den testen.
-- Vennlig hilsen Petter Reinholdtsen _______________________________________________ nikita-noark mailing list -- nikita-noark@nuug.no To unsubscribe send an email to nikita-noark-leave@nuug.no