Vælg database og adgangsbegrænsninger med kommandolinjeargumenter

[busstoptaktik]

Jf. #286: Der er ting, det er for besværligt at gøre for mennesker.

P.t. skifter man mellem test- og produktionsdatabaser og mellem "læs kun" og "læs+skriv" ved at flytte tekstblokke rundt i fire.ini. Det ville være smart, hvis man i stedet kunne vælge adgangstype med kommandolinjeomskiftere.

Fx:

• Uden valg: Læs fra produktionsdatabasen
• Valg af "læs+skriv": Skriv til testdatabasen
• Valg af "læs+skriv" + separat valg af "ja jeg vælger at skrive til produktionsdatabasen, men mind mig alligevel om det inden der skrives": Skriv til produktionsdatabasen
• Valg af "læs": Læs fra testdatabasen

[kbevers]

Fint, jeg har tænkt på noget lignende. Jeg kigger på det!

[busstoptaktik]

... du er da også mere end velkommen til at tage et blik på de øvrige nyoprettede problembeskrivelser, denne her så bare specifikt Evers-agtig ud, så her mente jeg godt at jeg kunne tillade mig at sætte dig direkte på som assignee. De andre må jeg jo nå til efterhånden, hvis ikke andre når at føle trang til at pille ved dem :-)

[busstoptaktik]

Muligvis er #257 også relevant her (lukkes potentielt af samme løsning som for dette issue)

[kbevers]

Inden jeg kaster mig over selve koden vil jeg gerne afklare interfacet først. Vi har 4 hovedindgange i fire applikationen:

• info
• søg
• niv
• gama

De første to er klokkeklare defaults op mod produktionsdatabasen. niv bør vel også være default mod produktion men med tilstrækkelige advarsler inden man indsætter i prod. gama er mindre vigtig men er nok samme sted som niv.

Umiddelbart forestiller jeg mig at uden yderligere tilvalg på kommondalinjen så får man ovenstående. Hvis man vil i test-databasen kan man tilføje --db=test. Med --db=prod kan man slå advarsler inden indsættelse fra.

Derudover kan vi også indføre en setting i fire.ini hvor default databasen sættes, fx default_connection = test_connection. På denne måde kan man under en workshop eller lign. sætte test-databasen som default en gang for alle og arbejde ubekymret videre uden at skulle eksplicit bede om test-databasen med --db=test.

Hvad siger du til den løsning @busstoptaktik ?

[busstoptaktik]

Det lyder fornuftigt, men belært de sidste dages erfaring med hvor svært det er at læse indenad vil jeg gerne undgå at slå advarsler fra: Hellere sætte tre låse på døren og leve med at de to bliver flået op, hvis bare den tredje får delinkventen til at stoppe op og overveje. Men det er selvfølgelig en afvejning: Hvor følelsesløse skal man gøre brugerne?

Så jeg er stadig mest tryg ved at læsning pr. automatik sker fra prod, mens skrivning sker til test: De (kun) to låse er at først skal du aktivt vælge prod, dernæst at du aktivt skal afgøre at "ja - det er det jeg mener".

I praksis er det sidste en afgørelse man kan tage med meget mere ro i sindet, hvis man først har set at det man har gjort giver en korrekt registrering i testdatabasen.

Det er her jeg mener at "test først" kan gøre situationen mere meningsfuld for en usikker bruger, og skabe en vej til større psykologisk sikkerhed hen ad vejen: Man KAN faktisk teste sine ting af (empowerment! på nudansk) før man tager stilling til om de er i orden, og man nudges til at gøre det på den måde ved at skrivning sker til test - og først til prodnår man aktivt vælger det.

Hvis du insisterer må jeg selvfølgelig bukke mig, men tilsvarende vil jeg insistere på at man ikke med et kommandolinjeflag kan slå "er du sikker?" fra. Vi kan selvfølgelig indrette det så det fungerer sammen med /usr/bin/yes, så man aktivt kan vælge at automatisere, når man er meget-meget-sikker på at man ikke er i gang med at skyde foden af

[kbevers]

men belært de sidste dages erfaring med hvor svært det er at læse indenad vil jeg gerne undgå at slå advarsler fra:

Så stryger jeg den ide for nu. Jeg tror dog vi lige nu er mere nervøse for at indlæse dårligt data end vi på sigt behøver være. Med en tilbagerulningsmekanisme ville der nok være mere ro i sindet.

Det er her jeg mener at "test først" kan gøre situationen mere meningsfuld for en usikker bruger, og skabe en vej til større psykologisk sikkerhed hen ad vejen: Man KAN faktisk teste sine ting af (empowerment! på nudansk) før man tager stilling til om de er i orden, og man nudges til at gøre det på den måde ved at skrivning sker til test - og først til prodnår man aktivt vælger det.

Jeg kan godt se hvor du vil hen med det, men jeg i tvivl om det i praksis kan lade sig gøre. PROD og TEST databaserne vil formentligt altid være forskellige, især lige nu hvor alle punkter har forskellige UUID'er. Så hvis man skal lave en test er man nødt til at starte arbejdet fra TEST og køre hele workflowet igennem inden indsættelse i databasen. Når man så har verificeret at det man gør fungerer, så skal man starte hele workflowet igen. En daglig spejling af PROD over i TEST kan måske mindske eller fjerne problemet helt.

Så jeg er stadig mest tryg ved at læsning pr. automatik sker fra prod, mens skrivning sker til test

Med afsæt i min kommentar ovenfor er jeg i tvivl om det giver mening men jeg kigger gerne nærmere på det. Kan du ikke pege på hvilke niv-operationer der læser henholdsvis skriver. Forhåbentligt er der ikke nogen der gør begge dele i samme omgang.

[busstoptaktik]

Med afsæt i min kommentar ovenfor er jeg i tvivl om det giver mening men jeg kigger gerne nærmere på det. Kan du ikke pege på hvilke niv-operationer der læser henholdsvis skriver. Forhåbentligt er der ikke nogen der gør begge dele i samme omgang.

Det er i hvert fald tydeligvis en vanskelig operation og jeg må tilstå at jeg ikke havde tænkt det længere igennem end at det kunne lade sig gøre ved at køre "først ren test, så ren prod", men det bliver jo noget rodet når man læser fra den ene side og skriver til den anden - især fordi, når vi først får din autolandsnummergenerator sat i fuld produktion, så vil der opstå kronsj så snart der er en sag der kun er kørt på den ene side af hegnet. Og selvfølgelig skal man have lov til at køre udelukkende på produktionssiden når man er klar til det...

Så spørgsmålet er om man ikke, som en pragmatisk mellemløsning med minimale kodeændringskrav simpelthen bare skal oprette to sager, når man kører fire niv opret-sag:

• Den ene oprettes i fire-prod og med et regneark med det anførte sagsnavn i det aktuelle bibliotek
• Den anden oprettes i fire-test og med et regneark med det anførte sagsnavn præfikset med TEST_ i underbiblioteket TEST

Så sørger vi for at når man kører en sag med et navn, der starter med TEST_, så er det testdatabasen der kommer i spil [1]. På den måde er vi sikre på at "turen på legepladsen" bliver tydeligt adskilt fra "de voksnes verden". Vi kan stadig overfylde brugeren med advarsler når vi nærmer os skrivning - både i test og i prodmiljøet.

[1] Eller måske snarere omvendt: Man kan kun komme til at arbejde i prod hvis ens sag ikke starter med TEST_

[busstoptaktik]

... og ved nærmere eftertanke, fordi der godt kan gå l-a-a-n-g tid fra en sag oprettes til den gennemføres, og testdatabasen i mellemtiden kan være overskrevet: Man kunne bare have en kommando fire niv opret-testsag (måske bare en option til fire opret-sag). Så kan man starte på en frisk hvornårsomhelst

[busstoptaktik]

Jeg tror dog vi lige nu er mere nervøse for at indlæse dårligt data end vi på sigt behøver være. Med en tilbagerulningsmekanisme ville der nok være mere ro i sindet

Vi ville komme langt med at få de alt for hyppige autocommits udryddet, så vi kan være mere sikre på at kunne teste at alt er i orden, før vi committer. Men det er jo også den vej vi glider når der kommer luft til det igen - din seneste tilpasning gør vel det meste?

[kbevers]

(måske bare en option til fire opret-sag)

Det vil jo i så fald blive til fire niv opret-sag --db=test som skitseret ovenfor. Her vil det så være smart hvis det er indikeret i regnearket på den eller måde at det hører til testdatabasen. Kan det puttes i en celle et sted i regnearket (måske blandt andre indstillinger?) eller skal det som du foreslår ovenfor præfikses på sagsnavnet? Hvis det kan laves som en slags indstilling kan man også med fordel skrive at det er myntet produktionsdatabasen i det modsatte tilfælde.

Vi ville komme langt med at få de alt for hyppige autocommits udryddet, så vi kan være mere sikre på at kunne teste at alt er i orden, før vi committer. Men det er jo også den vej vi glider når der kommer luft til det igen - din seneste tilpasning gør vel det meste?

Vi er nede på en håndfuld indset_*-funktioner nu, hvor det i praksis kun er indset_sag og indset_sagsevent der bruges i det daglige arbejde. Begge committer lige inden de afslutter, men det kan sagtens gøre optionelt, så man eksplicit skal committe eller rollbacke efterfølgende. Jeg vil tro det er muligt at lave en fire niv ilæg-* --test som kører et rollback efter indset_sagsevent. Alternativt kan man gøre det uden --test ved at køre indset_sagsevent(commit=False), rapportere hvis noget går galt og ellers spørge brugeren om indsættelsen skal gennemføres.

[busstoptaktik]

Det vil jo i så fald blive til fire niv opret-sag --db=test som skitseret ovenfor.

Smart!

rapportere hvis noget går galt og ellers spørge brugeren om indsættelsen skal gennemføres

Også smart! - problemet har været at der er rigtigt meget, der kan gå galt i punktrevisionsprocessen, så det er let at stå med et "halvt commit" og skulle udrede "hvor langt kom vi så egentlig?"

[busstoptaktik]

Kan det puttes i en celle et sted i regnearket (måske blandt andre indstillinger?)

I fanebladet Parametre, hvor vi i forvejen har plads til versionstriplet (p.t. bare sat til 0.0.0), som principielt også skal checkes ved hver start af fire niv xxx, så der er i forvejen lagt op til den slags, og det var bare mig, der tænkte for snævert ved at foreslå at overstyre filnavnet med den funktionalitet.

[kbevers]

Lukket med #310