Under demonstration i dag stødte vi ind i en sjov bug, som jeg regner med skyldes at vi var flere som oprettede punkter i databasen samtidig.
Vi oprettede alle sammen et nyt GI-punkt igennem det almindelige niv-workflow og kald af fire niv ilæg-nye-punkter. Ved ilægning får punktet så tildelt et GI-nummer og vi kunne bagefter konstatere at nogle af os havde fået tildelt det samme GI-nummer, hvilket ikke burde kunne ske. Der er både en løbenummer mekanisme i funktionen tilknyt_gi_numre som tildeler nye GI-numre, samt en database-trigger punktinfo_bi_trg som begge burde forhindre dette i at ske.
Jeg har desværre ikke haft tid til at kigge nærmere på det. Konsekvensen af denne fejl er dog ikke så stor, da der ikke burde være noget som "går i stykker" pga. af det, og hvis man konstaterer at der er dubletter, så kan man altid ændre GI-numrene igennem Punktrevision, hvilket også var den måde vi fiksede det på til demoen i dag.
Under demonstration i dag stødte vi ind i en sjov bug, som jeg regner med skyldes at vi var flere som oprettede punkter i databasen samtidig. Vi oprettede alle sammen et nyt GI-punkt igennem det almindelige niv-workflow og kald af
fire niv ilæg-nye-punkter. Ved ilægning får punktet så tildelt et GI-nummer og vi kunne bagefter konstatere at nogle af os havde fået tildelt det samme GI-nummer, hvilket ikke burde kunne ske. Der er både en løbenummer mekanisme i funktionentilknyt_gi_numresom tildeler nye GI-numre, samt en database-triggerpunktinfo_bi_trgsom begge burde forhindre dette i at ske.Jeg har desværre ikke haft tid til at kigge nærmere på det. Konsekvensen af denne fejl er dog ikke så stor, da der ikke burde være noget som "går i stykker" pga. af det, og hvis man konstaterer at der er dubletter, så kan man altid ændre GI-numrene igennem Punktrevision, hvilket også var den måde vi fiksede det på til demoen i dag.