Ana sayfa / Blog / Para

Masrafı düzenlemek bölüşümü neden yeniden belirtmeli

29 Ağustos 2026 · 7 dakika okuma · Dimesum Engineering

Bir düzenlemenin varsayılanları para hatası olduğundan Dimesum, eski bir düzenlemeyi birleştirmek yerine reddeden base_version ile birlikte participants ve split_type alanlarını her masraf düzenlemesinde zorunlu kılar

Bir yazım hatasını düzeltmek kimin borçlu olduğunu değiştirmemeli. Dimesum'da ortak bir masrafı düzenlemek bölüşümün tamamını yeniden belirtir. participants ve split_type her PATCH isteğinde zorunludur ve ikisinden birini atlayan bir düzenleme, varsayılan doldurmak yerine 400 döner. Oluşturma varsayılanları mevcut tüm üyeler ve eşit bölüşümdür; bir düzenlemede bunlar para hatasıdır.

İki hata durumu bunu somutlaştırır. Ağustos'ta katılan bir ev arkadaşı Temmuz'un yemeğine dahil edilir, çünkü "mevcut tüm üyeler" masraf yazıldığında değil düzenleme geldiğinde değerlendirilir. Bilinçli bir 70/30 kira bölüşümü 50/50'ye düzleşir, çünkü eksik bir split_type EQUAL anlamına gelir. Her iki hata da bir hata vermez ve ikisi de gerçek para taşır.

Oluşturma varsayılanları eski bir masrafı değil yeni bir masrafı tanımlar

Oluşturma zamanında varsayılanlar dürüsttür. Yazar gruba olduğu haliyle bakar ve herkes arasında eşit bölüşüm yaygın durumdur, bu yüzden Dimesum ikisini de doldurur. Masraf yalnızca sonuçlarını değil girdilerini saklar: splits.percent_bp, splits.weight ve splits.exact_minor kullanıcının yazdığını tutar, böylece sonraki bir düzenleme onu yeniden açabilir.

Bir düzenleme farklı bir eylemdir. Aynı masraf haftalar sonra, yeni bir ev arkadaşı katıldıktan ya da bir hayalet üye sahiplenildikten sonra düzeltilebilir. Üyelik hareketli bir hedeftir, bölüşüm değildir. Oluşturma varsayılanlarını yeniden kullanmak, eski masrafın zaten yanıtladığı bir soruyu bugünkü gruba sorar.

Tahmin etmeyi reddetmek burada yeni değildir. Çok ödemeli bir masraf ödeyenlerini de yeniden belirtmelidir. soleStoredPayer saklanan ödeyeni yalnızca masrafın tam olarak bir ödeyeni olduğunda yeniden kullanır, böylece iki ödeyen hakkında sessiz kalan bir düzenleme yeniden atanmak yerine reddedilir. Ödeyenler hakkında hiçbir şey söylemeyen bir düzenleme, düzenlemeyi yapan kişiyi değil masrafın kendi ödeyenini korur.

API bölüşümünü yeniden belirtmeyen bir düzenlemeyi reddeder

Ağ geçidi denetimi herhangi bir para hesaplanmadan önce çalışır. participants boş olduğunda veya split_type boş olduğunda, istek invalid_expense koduyla ve "an edit must restate the split: participants and split_type are required" mesajıyla 400 döner. Masraf hizmeti kuralı validateAmend içinde yineler, böylece hizmete başka bir yoldan ulaşan bir çağıran aynı reddi karşılar.

Para birimi aynı ret ailesine aittir. Bir düzenleme bir masrafın para birimini değiştiremez, çünkü bir bakiye satırı üye başına tek para birimi tutar. Yazma tarafı değişikliği reddeder ve yalnızca ekleme yapılan defter böyle bir değişiklik ona ulaşırsa onu park eder. Kapıda reddetmek iki yarının uyuşmazlığa düşmesini önler.

Eski bir düzenleme yazarı için reddedilir, asla birleştirilmez

base_version sözleşmenin diğer yarısıdır. Her PATCH yazarının okuduğu sürümü taşır ve checkTransition onu işlemin az önce kilitlediği satırla karşılaştırır. Eşitse, düzenleme sürüm artı bir olarak uygulanır. Farklıysa, çağıran stale_version koduyla HTTP 409 alır.

Birleştirmek cazip alternatiftir ve yanlıştır. Bir masrafa yapılan iki düzenleme, faturanın ne anlama geldiğine dair iki eksiksiz ifadedir. Onları birleştirmek, kimsenin yazmadığı üçüncü bir ifade üretir ve payları hiçbir yazar tanımaz. Reddetme, çatışmayı çözebilecek tek kişiye geri verir.

İdempotency ve eşzamanlılık bilinçli olarak ayrı tutulur. Revizyon eklemesi sürüm denetiminden önce çalışır, çünkü yeniden denenen bir düzenleme başta okuduğu temel sürümü taşır ve bu artık eskimiştir. Bir yeniden oynatma çatışma olarak değil yeniden oynatma olarak okunmalıdır, bu yüzden önce revision_id yanıtlar ve saklanan sonucu döner.

Yanıt bir sonraki düzenlemenin ihtiyaç duyduğunu zaten taşır

Bir PATCH'te daha fazla alan istemek, ancak bir istemci onları ucuza alabiliyorsa adildir. Her masraf yanıtı version taşır, böylece bir masrafı az önce yazan bir istemci onu ikinci bir okuma olmadan düzenleyebilir. Oluşturma yanıtı, değişiklik yanıtı ve her liste satırı aynı alanı taşır.

Masrafı az önce yazmayan istemci için GET /v1/groups/{id}/expenses/{id} sürümü, hesaplanan payları ve onların arkasındaki girdileri döner. Girdiler bir PATCH'in kabul ettiği aynı adlar altında geri gelir: participants, split_type, percents, weights, shares, items, pools. Bir istemci tek bir biçim okur ve düzenlemelerle geri gönderir, tek bir fatura için iki sözcük dağarcığı arasında çeviri yapmak yerine.

Bu bakışım en çok, yeniden kurulamayan bölüşümler için önemlidir. Bir PERCENT bölüşümü ya da kalem kalem bir fatura, yalnızca çözülmüş paylarından yeniden belirtilemez, çünkü yuvarlama zaten uygulanmıştır ve baz puanlar ile satır kalemleri gitmiştir. Revizyon anlık görüntüleri girdileri de taşır, böylece geçmiş sayfası herhangi bir geçmiş sürümde neyin kalemlendiğini gösterebilir.

Şimdi zorunlu, çünkü bir gereksinim sonradan eklenemez

Bir alanı ilk günden zorunlu kılmak, bugünle ilgili değil gelecekle ilgili bir karardır. Zorunlu bir alanı sonradan gevşetmek geriye dönük uyumludur: istemciler onu zaten gönderir ve sunucu onsuz gelen istekleri kabul etmeye başlar. Bir gereksinimi sonradan eklemek, eski varsayılana güvenen her istemciyi bozar.

Bu yüzden yön bir kez, erkenden seçilir. Dimesum, istemci sayısı hâlâ değiştirilebilecek kadar küçükken bir düzenlemede participants, split_type ve base_version'ı zorunlu kılar. Düzenlemeler için güvenli bir varsayılan bir gün bulunursa, alanlar isteğe bağlı olur ve halihazırda gönderilmiş hiçbir şey çalışmayı durdurmaz.