-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Materialisering av bruksenhet ved innkommende egenregistreringer #207
Conversation
Dependency ReviewThe following issues were found:
License Issuessettings.gradle.kts
Denied Licenses: AGPL-1.0-only, AGPL-1.0-or-later, AGPL-3.0, AGPL-3.0-or-later OpenSSF ScorecardScorecard details
Scanned Files
|
...rket/matrikkel/bygning/infrastructure/database/repositories/bygning/BygningRepositoryImpl.kt
Outdated
Show resolved
Hide resolved
...ket/matrikkel/bygning/infrastructure/database/repositories/EgenregistreringRepositoryImpl.kt
Outdated
Show resolved
Hide resolved
...ket/matrikkel/bygning/infrastructure/database/repositories/EgenregistreringRepositoryImpl.kt
Outdated
Show resolved
Hide resolved
...on/src/test/kotlin/no/kartverket/matrikkel/bygning/application/bygning/BygningServiceTest.kt
Outdated
Show resolved
Hide resolved
...rket/matrikkel/bygning/infrastructure/database/repositories/bygning/BygningRepositoryImpl.kt
Outdated
Show resolved
Hide resolved
...rket/matrikkel/bygning/infrastructure/database/repositories/bygning/BygningRepositoryImpl.kt
Outdated
Show resolved
Hide resolved
...o/kartverket/matrikkel/bygning/infrastructure/database/repositories/bygning/BruksenhetDTO.kt
Outdated
Show resolved
Hide resolved
...cation/src/main/kotlin/no/kartverket/matrikkel/bygning/application/bygning/BygningService.kt
Outdated
Show resolved
Hide resolved
...integrationTest/kotlin/no/kartverket/matrikkel/bygning/repositories/BygningRepositoryTest.kt
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Det er noen ting som må endres på hvis databasen trenger både til- og fra-dato. Dette kan bli et tema hvis man ønsker å hente ut flere rader for et gitt tidspunkt.
import java.time.Instant | ||
import java.util.* | ||
import kotlin.test.Test | ||
|
||
class BygningEgenregistreringAggregeringTest { | ||
private val bygningId = BygningId("00000000-0000-0000-0000-000000000001") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jeg sliter med å finne noen god forklaring på om dette er en akseptabel ting å gjøre. Det er jo ikke i henhold til noen standard jeg kan finne.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Er det et problem å ha "uekte" UUIDer for tester? Jeg så bare dette som en grei måte å deale med UUIDene i testing å gjøre, men vet ikke om det har noen potensielle konsekvenser
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jeg vet ikke jeg heller.
) { | ||
it.setObject( | ||
1, | ||
PGobject().apply { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Virker det ikke å bare sende en String? Hvis ikke, så kunne dette godt få en hjelpefunksjon. Kanskje til og med en fun PreparedStatement.setUuid(val index: Int, val uuid: UUID)
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fikk ikke det til, nei. Men enig i at det kunne vært en fin funksjon. Årnær!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fant ut her at det faktisk er lov å bruke setObject
direkte uten å spesifisere type for objektet. Tenker du det er fint med en liten hjelpefunksjon for UUID så man ikke må vite at man skal bruke setObject uansett, eller?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hva var det du kom frem til?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jeg lagde en egen funksjon, siden UUID blir såpass vanlig. Kan vurdere å lage en tilsvarende for JsonBlob, men droppet det i første omgang pga. usikkerhet rundt håndtering av ObjectMapperen
8330d92
to
8a3b7dc
Compare
Endrer med dette oppsettet for hvordan man henter ut bruksenhetsinfo. Tidligere har vi kjørt gjennom alle egenregistreringer ved uthenting, men nå applyer vi kun siste egenregistrering inn til en snapshot av bruksenheten når vi får inn nye egenregistreringer.
Har også gjort at vi bruker UUID internt over boble-IDer, som kan være starten på at vi går over til dette fremfor bobleIDer. Ikke helt sikker på hvordan vi burde håndtere UUIDer i testing, men for nå har jeg bare gått med "tulle"-UUIDer.
I tillegg til dette har jeg satt opp en del Value Classes for IDene, og renamet bobleIDene til å gjenspeile at det er bobleIDer.
Endrer også bruk av kotlinx serialisering i applikasjonsmodulen, da den var litt vel "intrusive" for applikasjonslogikk. Håpet var egentlig å bli kvitt serialiseringsimplementasjoner fullstendig, men på grunn av manglende "hjelp" på hva man deserialiserer av Signatur vs. Fødselsnummer så måtte vi annotere litt der.