Miksi jaetun kulun muokkaus vaatii jaon toistamisen
Muokkauksen oletukset ovat rahavirheitä, joten Dimesum vaatii jokaisessa kulun PATCH-kutsussa participants- ja split_type-kentät sekä base_version-kentän, joka hylkää vanhentuneen muokkauksen sen sijaan että yhdistäisi sen.
Kirjoitusvirheen korjaaminen ei saa muuttaa sitä, kuka on velkaa. Dimesumissa jaetun kulun muokkaus toistaa koko jaon. participants ja split_type vaaditaan jokaisessa PATCH-kutsussa, ja muokkaus, joka jättää jommankumman pois, palautuu virheellä 400 sen sijaan, että se täyttäisi oletusarvon. Luonnin oletukset ovat kaikki nykyiset jäsenet ja tasajako, jotka muokkauksessa ovat rahavirheitä.
Kaksi virhettä tekevät asian konkreettiseksi. Elokuussa mukaan tullut kämppäkaveri vedetään heinäkuun illalliseen, koska "kaikki nykyiset jäsenet" arvioidaan silloin, kun muokkaus tehdään, ei silloin, kun kulu kirjattiin. Tarkoituksellinen 70/30-vuokrajako tasoittuu 50/50:ksi, koska puuttuva split_type tarkoittaa EQUAL. Kumpikaan virhe ei nosta virheilmoitusta, ja molemmat siirtävät oikeaa rahaa.
Muokkauksen oletukset ovat rahavirheitä. Luontihetken oletus arvaa sen ryhmän, jota tekijä katsoo juuri nyt. Muokkaus saapuu myöhemmin, ryhmään joka on muuttunut, ja sama arvaus kirjoittaa hiljaa uudelleen sen, mitä ihmiset ovat velkaa.
Luonnin oletukset kuvaavat uutta kulua, eivät vanhaa
Luontihetkellä oletukset ovat rehellisiä. Tekijä katsoo ryhmää sellaisena kuin se on, ja tasajako kaikkien kesken on tavallisin tilanne, joten Dimesum täyttää molemmat. Kulu tallentaa syötteensä eikä vain tuloksiaan: splits.percent_bp, splits.weight ja splits.exact_minor säilyttävät sen, mitä käyttäjä kirjoitti, joten myöhempi muokkaus voi avata sen uudelleen.
Muokkaus on eri teko. Sama kulu voidaan korjata viikkoja myöhemmin, kun uusi kämppäkaveri on tullut mukaan tai haamujäsen on lunastettu. Jäsenyys on liikkuva kohde, jako ei ole. Luonnin oletusten uudelleenkäyttö pyytää tämän päivän ryhmää vastaamaan kysymykseen, johon vanha kulu on jo vastannut.
Kieltäytyminen arvaamasta ei ole täällä uutta. Monimaksajaisen kulun on toistettava myös maksajansa. soleStoredPayer käyttää tallennettua maksajaa uudelleen vain silloin, kun kulussa on täsmälleen yksi, joten muokkaus, joka vaikenee kahdesta maksajasta, hylätään eikä sitä kohdenneta uudelleen. Muokkaus, joka ei sano maksajista mitään, säilyttää kulun oman maksajan, ei koskaan muokkaajaa.
Rajapinta hylkää muokkauksen, joka ei toista jakoaan
Yhdyskäytävän tarkistus suoritetaan ennen kuin mitään rahaa lasketaan. Kun participants on tyhjä tai split_type on tyhjä, pyyntö palautuu virheellä 400 koodilla invalid_expense ja viestillä "an edit must restate the split: participants and split_type are required". Kulupalvelu toistaa säännön kohdassa validateAmend, joten toista reittiä palveluun tuleva kutsuja kohtaa saman hylkäyksen.
| Kenttä | Luonnissa | Muokkauksessa | Mitä oletus maksaisi |
|---|---|---|---|
participants | Valinnainen. Oletuksena kaikki nykyiset jäsenet | Pakollinen | Myöhemmin liittynyt jäsen liittyy vanhaan kuluun |
split_type | Valinnainen. Oletuksena EQUAL | Pakollinen | 70/30-jako tasoittuu 50/50:ksi |
payers | Valinnainen. Oletuksena tekijä | Pois jätettynä säilyy kulun ainoa maksaja; kaksi maksajaa on toistettava | Muokkaajasta tulee maksaja, mikä kääntää sen, kuka on kenellekin velkaa |
base_version | Ei lähetetä | Pakollinen, ja sen on vastattava nykyistä versiota | Vanhentunut muokkaus korvaa muutoksen, jota sen tekijä ei koskaan lukenut |
revision_id | Asiakkaan UUIDv7, idempotenssiavain | Sama, yksi versiota kohden | Uudelleen yritetty muokkaus veloittaa ryhmää kahdesti |
currency | Ilmoitetaan kulukohtaisesti | Täytyy täsmätä; muutos hylätään | Saldorivi sisältää yhden valuutan jäsentä kohden |
Valuutta kuuluu samaan hylkäysten perheeseen. Muokkaus ei voi muuttaa kulun valuuttaa, koska saldorivi sisältää yhden valuutan jäsentä kohden. Kirjoituspuoli hylkää muutoksen, ja lisäävä kirjanpito pysäköi tällaisen muutoksen, jos sellainen koskaan sinne pääsee. Ovella hylkääminen estää näitä kahta puoliskoa olemasta eri mieltä.
Vanhentunut muokkaus hylätään tekijälleen, ei koskaan yhdistetä
base_version on sopimuksen toinen puolisko. Jokainen PATCH kantaa version, jonka sen tekijä luki, ja checkTransition vertaa sitä riviin, jonka transaktio juuri lukitsi. Yhtä suuri, ja muokkaus astuu voimaan versiolla plus yksi. Erilainen, ja kutsuja saa HTTP 409 koodilla stale_version.
Yhdistäminen on houkutteleva vaihtoehto, ja se on väärä. Kaksi muokkausta yhteen kuluun ovat kaksi täydellistä lausumaa siitä, mitä lasku tarkoittaa. Niiden yhdistäminen tuottaa kolmannen lausuman, jota kukaan ei kirjoittanut, osuuksilla joita kumpikaan tekijä ei tunnistaisi. Hylkäys antaa ristiriidan takaisin sille yhdelle henkilölle, joka voi ratkaista sen.
Idempotenssi ja samanaikaisuus pidetään tarkoituksella erillään. Revision lisäys suoritetaan ennen version tarkistusta, koska uudelleen yritetty muokkaus kantaa alun perin lukemaansa perusversiota, joka on nyt vanhentunut. Uusinnan on luettava uusintana eikä ristiriitana, joten revision_id vastaa ensin ja palauttaa tallennetun tuloksen.
Vastaus kantaa jo sen, mitä seuraava muokkaus tarvitsee
Useampien kenttien vaatiminen PATCH-kutsussa on reilua vain, jos asiakas saa ne edullisesti. Jokainen kuluvastaus kantaa version-kentän, joten asiakas, joka juuri kirjoitti kulun, voi muokata sitä ilman toista lukua. Luontivastaus, muokkausvastaus ja jokainen listarivi kantavat saman kentän.
Asiakkaalle, joka ei juuri kirjoittanut kulua, GET /v1/groups/{id}/expenses/{id} palauttaa version, lasketut osuudet ja niiden takana olevat syötteet. Syötteet palaavat samoilla nimillä, jotka PATCH hyväksyy: participants, split_type, percents, weights, shares, items, pools. Asiakas lukee yhden muodon ja lähettää sen takaisin muokkauksineen sen sijaan, että kääntäisi kahden sanaston välillä yhtä laskua varten.
Symmetria on tärkein niille jaoille, joita ei voi rakentaa uudelleen. PERCENT-jakoa tai eriteltyä laskua ei voi toistaa pelkästään sen ratkaistuista osuuksista, koska pyöristys on jo tehty ja peruspisteet ja rivikohteet ovat poissa. Revision tilannekuvat kantavat myös syötteet, joten historialehti voi näyttää, mitä missäkin aiemmassa versiossa oli eritelty.
Pakollinen nyt, koska vaatimusta ei voi lisätä myöhemmin
Kentän vaatiminen ensimmäisenä päivänä on päätös tulevaisuudesta eikä tästä päivästä. Pakollisen kentän lieventäminen myöhemmin on taaksepäin yhteensopivaa: asiakkaat lähettävät sen jo, ja palvelin alkaa hyväksyä pyyntöjä ilman sitä. Vaatimuksen lisääminen myöhemmin rikkoo jokaisen asiakkaan, joka luotti vanhaan oletukseen.
Joten suunta valitaan kerran, varhain. Dimesum vaatii muokkauksessa participants, split_type ja base_version silloin, kun asiakkaiden määrä on vielä tarpeeksi pieni muutettavaksi. Jos muokkauksille löytyy koskaan turvallinen oletus, kentistä tulee valinnaisia eikä mikään jo julkaistu lakkaa toimimasta.
Anna muokkauksen toistaa se, mitä se tarkoittaa
Oletukset kuuluvat luontiin, jossa tekijä näkee ryhmän, johon hän suostuu. Muokkauksessa samat oletukset ovat arvaus ryhmästä, joka on sittemmin muuttunut. Seuraava askeleesi: avaa oma lukupäätepisteesi ja tarkista, että se palauttaa jaon syötteet täsmälleen niillä kenttänimillä, jotka kirjoituspäätepisteesi hyväksyy. Asiakas, jonka on käännettävä näiden kahden välillä, kääntää lopulta toisen niistä väärin.
Usein kysytyt kysymykset
Miksi jaetun kulun muokkaus vaatii kentät <code>participants</code> ja <code>split_type</code>?
Dimesum vaatii molemmat kentät, koska luonnin oletukset ovat väärät muokkaukselle. Luonnissa Dimesum käyttää oletuksena kaikkia nykyisiä jäseniä ja tasajakoa, mikä vastaa ryhmää, jota tekijä katsoo. Muokkaus voi saapua viikkoja myöhemmin, sen jälkeen kun joku on liittynyt. Näiden oletusten uudelleenkäyttö vetäisi uuden kämppäkaverin vanhaan illalliseen ja tasoittaisi tarkoituksellisen 70/30-vuokrajaon takaisin 50/50:ksi ilman että virhettä näytetään.
Mitä tapahtuu, kun kaksi henkilöä muokkaa samaa kulua samaan aikaan?
Toinen muokkaus hylätään HTTP 409:llä ja virhekoodilla stale_version. Jokainen PATCH kantaa base_version-kentän, sen version jonka sen tekijä luki, ja muokkauspolku vertaa sitä lukittuun riviin. Ero tarkoittaa, että kulu on liikkunut, joten muokkaus palaa tekijälleen sovellettavaksi uudelleen sitä versiota vasten, jonka hän voi nyt nähdä. Mitään ei yhdistetä.
Päivittääkö kulun muokkaus kirjanpidon rivit paikallaan?
Ei, kulun muokkaus ei koskaan päivitä kirjanpidon riviä Dimesumissa. Muokkaus kirjaa kaksi vientiä yhdessä transaktiossa: EXPENSE_REVERSAL-viennin, joka kumoaa vanhan version haara haaralta, ja sitten EXPENSE-viennin uudelle versiolle. UPDATE ja DELETE on peruutettu kirjanpidon omalta tietokantaroolilta, joten muutos on mahdoton jopa viallisellekin koodille. Näet muokattu-merkin ja historialehden.
Tarvitseeko jaetun kulun muokkaus toisen rajapintakutsun?
Ei, asiakas joka juuri kirjoitti kulun, pitää jo hallussaan version jonka muokkaus tarvitsee. Jokainen kuluvastaus kantaa version-kentän, joka on se, minkä seuraava PATCH lähettää nimellä base_version. Asiakas joka ei kirjoittanut kulua, kutsuu GET /v1/groups/{id}/expenses/{id}, joka palauttaa version sekä jaon syötteet samoilla kenttänimillä, jotka PATCH hyväksyy.
Miksi osallistujat ja jakotapa vaaditaan heti eikä myöhemmin?
Kentän vaatiminen ensimmäisenä päivänä on peruutettavissa, sen lisääminen myöhemmin ei ole. Pakollisen kentän lieventäminen myöhemmin on taaksepäin yhteensopivaa: asiakkaat lähettävät sen jo, ja palvelin alkaa hyväksyä pyyntöjä ilman sitä. Vaatimuksen lisääminen myöhemmin rikkoo jokaisen asiakkaan, joka luotti vanhaan oletukseen, ja raharajapinnassa rikkoutuminen on hiljainen, kunnes jonkun saldo on väärin.
Suositut artikkelit
- Lisäävä kirjanpito pitää jaetut saldot täsmällisinä7 min lukuaika
- Kuusi rahavirhettä monivaluuttaisessa kulujen jaossa7 min lukuaika
- Näin tasaat ryhmän kulut harvemmilla siirroilla4 min lukuaika
- Eritellyn laskun jakaminen reilusti7 min lukuaika
- Vuokran reilu jako kämppisten kesken4 min lukuaika