Tek bir hata toplu işlemde başarısız mı olmalı?


11

Üzerinde çalıştığım API'de, bir dizi kimliği kabul eden bir toplu silme işlemi var:

["1000", ..., "2000"]

Uygun gördüğümde silme işlemini uygulamakta özgürdüm, bu yüzden her şeyi işlem yapmaya karar verdim: yani, tek bir kimlik geçersizse, tüm istek başarısız olur. Buna katı mod diyeceğim .

try{
savepoint = conn.setSavepoint();

for(id : IDs)
    if( !deleteItem(id) ){
        conn.rollback(savepoint);
        sendHttp400AndBeDoneWithIt();
        return;
    }

conn.commit();
}

Alternatif (yazılım paketimizin başka bir yerinde uygulanır) arka uçta elimizden geleni yapmak ve bir dizideki hataları bildirmektir. Yazılımın bu kısmı daha az istekle ilgilenir, böylece yanıt teoride dev bir dizi haline gelmez.


Kaynak yetersiz bir sunucuda son zamanlarda meydana gelen bir hata beni tekrar koda bakmamı sağladı ve şimdi orijinal kararımı sorguluyorum - ama bu sefer en iyi uygulamalardan ziyade iş ihtiyaçlarına göre motive oldum. Örneğin, tüm isteği başarısız olursa, kullanıcı tekrar denemek zorunda kalacak, oysa birkaç öğe silinirse, kullanıcı eylemi bitirebilir ve daha sonra bir yöneticiden geri kalanını yapmasını isteyebilir (hatayı düzeltmeye çalışırken) !). Bu izin veren mod olurdu .

Bu konuda bazı rehberlik için çevrimiçi bakmaya çalıştım ama boş teslim oldum. Size geliyorum: Bu nitelikteki toplu operasyonlardan en çok ne bekleniyor? Daha fazla sıkıya bağlı kalmalı mıyım yoksa daha fazla müsaade etmeli miyim?


9
Değişir. Silinmeyen bir şeyin olması gerektiğinde maliyeti nedir? (Maliyet kötü veri, baş ağrısı, istenmeyen davranış, bir yöneticinin bunu düzeltmesi için geçen süre vb.) Olarak tanımlanır.) Kabul edilebilir mi? Her şeyi başarısızlığa uğratmamanın sonuçlarıyla yaşayabiliyorsanız, bunun için gidin. Çok fazla soruna neden olacaksa, yapma. Yazılımınızı ve sonuçlarını biliyorsunuz, bu yüzden bir karar araması yapmanız gerekecek.
Becuzz

1
@Becuzz Maliyet, kullanıcının bir veya iki artıkları fark etmesi ve bunun hakkında bir bilet açmasıdır; mevcut durum "omg delete broken". Neyse ki kullanıcı koridorda olduğunu, bu yüzden bu sefer çok fazla bir sorun değil. Mesele şu ki, mümkün olan en doğru şeyi yapmaktan hoşlanıyorum ve 10'dan fazla yaşındaki bir kod tabanı ile Tanrı bazı şeylerin doğru bir şekilde yapılabileceğini biliyor
rath

Bence bu aynı zamanda ölçeklenebilirlik isteyip istemediğinize de bağlıdır. Çok fazla kimlik sahibi olmak istemiyorsanız, çok fazla önemli olmamalıdır. Bir milyon kimliğiniz veya daha iyisi olmasını istiyorsanız, bunun gerçekleşmeyeceğinden kesinlikle emin değilseniz, 1 geçersiz kimlik nedeniyle tamamen sıfırlanması için kimlikleri silmek için bir saat harcayabilirsiniz.
imnota4

1
@ imnota4 Düşünmediğim mükemmel bir nokta. Kullanıcı arabirimi, talebi en fazla yaklaşık 250 ile sınırlar, ancak arka ucun herhangi bir kısıtlaması yoktur. Yorumunuzu cevap olarak tekrar göndermenizi isteyebilir miyim?
rath

1
İzin veren mod, aynı zamanda tüm id yığınlarıyla hatayı yeniden üretmeleri gerekmediği için Admins işini de kolaylaştırır. Yanıtta her hatanın nedenini bildirmek de yararlı olabilir. Sebeplere bakıldığında, son kullanıcının "omg delete is broken" bileti olmadan çözmesi mümkün olabilir.
Laiv

Yanıtlar:


9

Silme uç noktasının 'katı' veya 'güzel' bir versiyonunu yapmak iyidir, ancak kullanıcıya ne olduğunu açıkça söylemeniz gerekir.

Bu uç nokta ile silme işlemi yapıyoruz. Muhtemelen DELETE /resource/bulk/ya da benzer bir şey. Seçici değilim. Burada önemli olan, katı veya hoş olmaya karar verirseniz, tam olarak ne olduğunu rapor etmeniz gerektiğidir.

Örneğin, birlikte çalıştığım bir API'nın DELETE /v1/student/toplu kimlikleri kabul eden bir bitiş noktası vardı . Test sırasında düzenli olarak isteği gönderir, bir 200yanıt alır ve her şeyin yolunda olduğunu varsayarız, ancak daha sonra listedeki herkesin hem veritabanında IN (hala etkin değil olarak ayarlandı) olduğunu hem de bir hata nedeniyle gerçekten silinmediğini öğrenmek için GET /v1/studentbeklemediğimiz verileri geri aldığımız için gelecekteki çağrıları berbat etti .

Bunun çözümü, silinmemiş kimlikleri içeren yanıta bir gövde ekleyen daha sonraki bir güncellemede geldi. Bu - bildiklerime göre - bir tür en iyi uygulamadır.

Alt satır, ne yaparsanız yapın, son kullanıcıya neler olduğunu ve muhtemelen neden olduğunu bildirmek için bir yol sağladığınızdan emin olun. IE, katı bir format seçtiysek, cevap olabilir 400 - DELETE failed on ID 1221 not found. 'Güzel' bir sürüm seçtiysek, bu olabilir 207 - {message:"failed, some ids not deleted", failedids:{1221, 23432, 1224}}(benim zavallı json biçimlendirmemle özür dilerim).

İyi şanslar!


6
207 Multi-Statuskısmi başarısızlık yanıtı için uygun olabilir
Richard Tingle

1
ORAYA GİDİYORUZ! Aslında hatırlayamıyordum! Devam edeceğim ve cevabı bununla güncelleyeceğim, çünkü bu aslında standartlara bağlı.
Adam Wells

2

Kişi katı ve müsamahakar olmalıdır.

Genellikle, dökme yükler 2 aşamaya ayrılır:

  • onaylama
  • Yükleniyor

Doğrulama aşamasında, veri spesifikasyonlarının gerekliliklerini karşıladığından emin olmak için her kayda kesinlikle bakılır. Bir kaç saniyede 1000'lerin 10'unu kolayca inceleyebilir. Geçerli kayıtlar yüklenecek yeni bir dosyaya yerleştirilir, geçersiz kayıtlar işaretlenir ve kaldırılır ve genellikle ayrı bir dosyaya (atlama dosyası) konur. Daha sonra, doğrulama işleminin başarısız olduğu kayıtlara bildirimler gönderilir, böylece sorun giderme amacıyla incelenebilir ve teşhis edilebilir.

Veriler doğrulandıktan sonra yüklenir. Genellikle uzun süren işlemlerden kaçınmak için yeterince büyükse veya bir arıza varsa, toplu olarak yüklenir. Toplu iş boyutu, veri kümesinin büyüklüğüne bağlıdır. Birinin yalnızca birkaç 1000 kaydı varsa, bir toplu işlem tamam olacaktır. Burada hatalara biraz izin verebilirsiniz, ancak biri tüm işlemi durdurmak için başarısız bir toplu eşik ayarlamak isteyebilir. Belki [N] toplu iş başarısız olursa, tüm işlem durdurulur (sunucu kapalıysa veya buna benzer bir şey varsa). Genellikle, veriler zaten doğrulanmış olduğundan bu noktada hiçbir hata yoktur, ancak ortam sorunları veya başka bir sorun nedeniyle varsa, başarısız olan toplu iş (ler) i yeniden yükleyin. Bu iyileşmeyi biraz daha kolaylaştırır.


Kimlikleri DB değerlerine göre doğrulamıyorum, bunları silmeye ve bunun nasıl gittiğini görmeye çalışıyorum, yoksa sonsuza kadar sürecek. N başarısızlıktan sonra iptal etmek çok makul bir öneri gibi görünüyor, +1
rat

2

Tek bir hata toplu işlemde başarısız mı olmalı?

Bunun kanonik bir yanıtı yok. Kullanıcının ihtiyaçları ve sonuçları incelenmeli ve ödünleşmeler değerlendirilmelidir. OP gerekli bilgilerin bir kısmını verdi, ama işte nasıl devam edeceğim:

Soru 1 : 'Bireysel bir silme işlemi başarısız olursa kullanıcının sonucu nedir?'

Cevap, geri kalan tasarım / uygulanan davranışı yönlendirmelidir.

OP türünün belirttiği gibi, sadece kullanıcı istisnayı fark ederse ve bir sorunlu bilet açarsa, ancak aksi halde etkilenmezse (silinmeyen öğeler sonraki görevleri etkilemez), o zaman otomatik bir bildirim ile izinli olarak giderdim sana.

Başarısız olan silme işlemlerinin, kullanıcının devam etmeden önce çözülmesi gerekiyorsa, kesin olarak açıkça tercih edilir.

Kullanıcıya seçenek vermek (örneğin, varsayılan olarak katı veya izin verilen bir yoksayma hatası bayrağı) en kullanıcı dostu yaklaşım olabilir.

Soru 2 : 'Hala veri deposunda silinmemiş öğelerle sonraki görevler gerçekleştirilirse veri tutarlılığı / tutarlılığı sorunları olur mu?'

Yine, cevap en iyi tasarımı / davranışı yönlendirecektir. Evet -> Sıkı, Hayır -> İzin Verici, Belki -> Sıkı veya Kullanıcı Seçildi (özellikle kullanıcı sonuçları doğru bir şekilde belirlemek için kullanılabilirse).


0

Bunun ölçeklenebilirlik isteyip istemediğinize bağlı olduğunu düşünüyorum. Çok fazla kimlik sahibi olmak istemiyorsanız, çok fazla önemli olmamalıdır. Bir milyon kimliğiniz veya daha iyisi olmasını istiyorsanız, bunun gerçekleşmeyeceğinden kesinlikle emin değilseniz, 1 geçersiz kimlik nedeniyle tamamen sıfırlanması için kimlikleri silmek için bir saat harcayabilirsiniz.


-1

Burada önemli bir nokta, bir sürü şeyin silinmesinin ne anlama geldiğini söyleyebilirim .

Bu kimlikler bir şekilde mantıklı bir şekilde ilişkili mi, yoksa bunların kolaylık / performans - toplu gruplaması mı?

Bir şekilde, hatta gevşek olsa bile, ben giderdim strict. Bu sadece bir toplu iş modu (örneğin, kullanıcı çalışma son dakikaları için "kaydet" tıklar ve ancak o zaman toplu iş iletilir) sonra permissivesürüm için gitmek istiyorum .

Diğer yanıtın belirttiği gibi: Her durumda "kullanıcıya" tam olarak ne olduğunu söyleyin.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.