refactor_accounts #17
No reviewers
Labels
No labels
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
banquise/laundering!17
Loading…
Reference in a new issue
No description provided.
Delete branch "refactor_accounts"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
1er truc a faire : fix les serialisation avec des DTO, car actuellement ca fait des loops infinie
refactor_accountsto WIP: refactor_accounts@ -0,0 +14,4 @@@Column(nullable = false) var iban: String = ""@OneToMany(mappedBy = "bankAccount", cascade = [CascadeType.ALL], orphanRemoval = true)var transactions: MutableList<Transaction> = ArrayList()56de0d97d3to8c8ab4ee86@ -0,0 +8,4 @@@Table(name = "bank_accounts")class BankAccount {@Id @GeneratedValue(strategy = GenerationType.IDENTITY) var id: Long? = null@Column(nullable = false, length = 100) var name: String = "New Bank Account"why not string vide ?
@ -0,0 +14,4 @@@Column(nullable = false) var iban: String = ""@OneToMany(mappedBy = "bankAccount", cascade = [CascadeType.ALL], orphanRemoval = true)var transactions: MutableList<Transaction> = ArrayList()mutableListOf()
@ -0,0 +8,4 @@@Table(name = "sub_accounts")class SubAccount {@Id @GeneratedValue(strategy = GenerationType.IDENTITY) var id: Long? = null@Column(nullable = false, length = 100) var name: String = "New Sub Bank Account"meme chose que pour BankAccount.kt
@ -0,0 +12,4 @@@ApplicationScopedclass BankAccountRepository : PanacheRepository<BankAccount> {fun getBankAccount(accountId: Long): Optional<BankAccount> {why optional et pas
BankAccount?j prefere, les optionnal rende le code + lisible puis ca rend les erreurs + propres que "null ptr", sans que ca perde specialement de perf
apres j suis pas non plus pret a defendre les optionnal a mort hein, ca a juste l'air + propre
en fait mb vaut juste enelver le optionnal/null, vaut juste mettre le type de retour et on throw une erreur dans la fonction qui appelle, mais oui faut pas se trainer d optionnal / de null
@ -0,0 +20,4 @@// TODO : Check for null and/or duplicatesaccount.transactions.add(transaction)persist(account)return truesartek le return True, return rien ou check les erreurs
oui vaut mieux pas return
@ -0,0 +19,4 @@fun createAccount(request: NewBankAccountRequest): BankAccount {// TODO list :// - Check for null and/or duplicates// - Validate ibancf. la rfc qui concerne les ibans (ou ISO jsp)
la rfc pour les iban ?
@ -0,0 +21,4 @@// - Check for null and/or duplicates// - Validate ibanval newAccount = BankAccount().apply { name = request.name; iban = request.iban };tu va pas link les subaccount ?
si ?
pas sur de comprendre la question
@ -0,0 +28,4 @@}fun getAllAccounts(): List<BankAccount> {return bankAccountRepository.findAll().list<BankAccount>()move to le repo sah
oui mais faut penser a garder la fonction exposee dans service car on en a besoin dans l api
@ -0,0 +32,4 @@}fun getAccount(accountId: Long): BankAccount {val account : Optional<BankAccount> = bankAccountRepository.getBankAccount(accountId)getAccount et getBackAccount faut se mettre d'accord sur le naming, encore une fois why les optional
go sur
getBankAccount@ -0,0 +40,4 @@}fun getAllSubAccounts(accountId: Long): List<SubAccount> {return getAccount(accountId).subAccountsmaybe move to repo ?
ba non on en a besoin dans rest
@ -0,0 +48,4 @@if (account.isEmpty) {throw Error("Account with id $accountId does not exist");}return account.get().transactions.map { transaction -> transaction.amount }.sumOf { i -> i }vaut pas mieux stocker la valeur plutot que sum toutes les transa ?
apres avoir pas mal bidouille avec c est assez foireux, vaut mieux sum quand un appel est fait sur un
/account/sum/de l api puis cache le result tant que y a pas de nouvelles transactions (a voir comment ca marche plus tard)@ -0,0 +56,4 @@// TODO : Check for null and/or duplicatesaccount.subAccounts.add(subAccount)persist(account)return truereturn true sans check d'erreur sympa
@ -0,0 +64,4 @@// TODO : Check for null and/or duplicatesaccount.transactions.add(transaction)persist(account)return truepareil
@ -0,0 +17,4 @@) {@Transactionalfun createAccount(request: NewSubAccountRequest): BankAccountResponse {c'est le meme code a peu de chose pres que pour les parent, tu peux pas mutualisé ?
nop, c est vraiment la v0 des account donc ils ont pas bcp de diffs pour le moment mais y ne aura d autres tres bientot, puis le but de la nouvelle "archi" avec 2 types de comptes, c est d avoir 2 objects bien disctinct en separes autremenet que par un booleen
@ -0,0 +16,4 @@import jakarta.ws.rs.core.Responseimport java.util.Optional@Path("/api/bank")/api/bank et /api/sub ???? relou un peu
c'est pas le prime de la naming convention
@ -0,0 +37,4 @@@GET@RolesAllowed("\${roles-admin}") // Todo: que les admin d un compte peuvent y acceder@Path("/account/")fun getAllBankAccounts(ca inclut les sub ou pas ?
nan c'est bon j'ai eu ma reponse
@ -0,0 +10,4 @@val id: Long,val name: String,val createdAt: LocalDateTime,val updatedAt: LocalDateTime,ca sert a rien de renvoyer createdAt, updatedAt et allowedRols ?
@ -0,0 +24,4 @@createdAt = createdAt,updatedAt = updatedAt,iban = iban,transactionsId = transactions.map { it.id!! }.toMutableList(),sur un get bank account, ya pas besoin d'inclure les transactions, imo c'est mieux si ca va sur un get /transaction/
@ -0,0 +12,4 @@val updatedAt: LocalDateTime,val transactionsId: MutableList<Long>,val bankAccountId: Long,val allowedGroups: Set<String>same remarque as au dessus
WIP: refactor_accountsto refactor_accounts