ความล้มเหลวเดียวควรล้มเหลวในการดำเนินการเป็นกลุ่ม?

ใน API ฉันทำงานอยู่มีการดำเนินการลบจำนวนมากซึ่งยอมรับอาร์เรย์ของ ID:

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

ฉันมีอิสระที่จะใช้การดำเนินการลบตามที่ฉันเห็นสมควรดังนั้นฉันตัดสินใจที่จะทำธุรกรรมทั้งหมด: นั่นคือถ้า ID เดียวไม่ถูกต้องคำขอทั้งหมดล้มเหลว ฉันจะเรียกสิ่งนี้ว่าโหมดเข้มงวด

try{
savepoint = conn.setSavepoint();

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

conn.commit();
}

ทางเลือก (นำไปใช้ที่อื่นในชุดซอฟต์แวร์ของเรา) คือทำสิ่งที่เราทำได้ในแบ็กเอนด์และรายงานความล้มเหลวในอาเรย์ ส่วนหนึ่งของซอฟต์แวร์นั้นเกี่ยวข้องกับคำขอที่น้อยลงดังนั้นการตอบสนองจึงไม่ได้กลายเป็นอาร์เรย์ขนาดใหญ่ ... ในทางทฤษฎี

ข้อผิดพลาดล่าสุดที่เกิดขึ้นในเซิร์ฟเวอร์ที่มีทรัพยากรต่ำทำให้ฉันดูรหัสอีกครั้งและตอนนี้ฉันตั้งคำถามกับการตัดสินใจเดิมของฉัน - แต่คราวนี้ฉันมีแรงจูงใจมากขึ้นตามความต้องการทางธุรกิจมากกว่าแนวทางปฏิบัติที่ดีที่สุด ตัวอย่างเช่นถ้าฉันล้มเหลวในการร้องขอทั้งหมดผู้ใช้จะต้องลองอีกครั้งในขณะที่หากมีการลบรายการจำนวนหนึ่งผู้ใช้สามารถดำเนินการให้เสร็จสิ้นแล้วขอให้ผู้ดูแลระบบทำส่วนที่เหลือ (ในขณะที่ฉันแก้ไขข้อผิดพลาด !) นี่จะเป็นโหมดที่ได้รับอนุญาต

ฉันพยายามหาคำแนะนำเกี่ยวกับเรื่องนี้ทางออนไลน์ แต่ฉันกลับมามือเปล่า ดังนั้นฉันมาหาคุณ: สิ่งที่คาดหวังมากที่สุดจากการดำเนินการเป็นจำนวนมากในลักษณะนี้? ฉันควรจะเข้มงวดมากขึ้นหรือฉันควรจะได้รับอนุญาตมากขึ้น?

ไม่เป็นไรที่จะทำจุดปลายลบ 'เข้มงวด' หรือ 'ดี' แต่คุณต้องบอกผู้ใช้อย่างชัดเจนว่าเกิดอะไรขึ้น

เรากำลังดำเนินการลบกับจุดสิ้นสุดนี้ ดูเหมือนDELETE /resource/bulk/หรือคล้ายกัน ฉันไม่จู้จี้จุกจิก สิ่งที่สำคัญที่นี่คือไม่ว่าคุณจะเข้มงวดหรือดีคุณต้องรายงานกลับสิ่งที่เกิดขึ้น

ตัวอย่างเช่น API ที่ฉันทำงานด้วยมีDELETE /v1/student/จุดปลายที่รับรหัสจำนวนมาก เราส่งคำขอเป็นประจำในระหว่างการทดสอบรับการ200ตอบกลับและคิดว่าทุกอย่างเรียบร้อยดีเท่านั้นที่จะค้นพบในภายหลังว่าทุกคนในรายการเป็นทั้งในฐานข้อมูลยัง (ตั้งค่าเป็นไม่ใช้งาน) หรือไม่ถูกลบจริงเนื่องจากข้อผิดพลาด ทำให้การโทรในอนาคตสับสนGET /v1/studentเพราะเราได้รับข้อมูลกลับมาซึ่งเราไม่ได้คาดหวัง

วิธีแก้ไขปัญหานี้มาในการอัปเดตในภายหลังซึ่งเพิ่มเนื้อหาลงในการตอบกลับด้วยรหัสที่ไม่ถูกลบ นี่คือ - สำหรับความรู้ของฉัน - เป็นแนวปฏิบัติที่ดีที่สุด

บรรทัดล่างไม่ว่าคุณจะทำอะไรตรวจสอบให้แน่ใจว่าคุณมีวิธีที่จะให้ผู้ใช้ทราบว่าเกิดอะไรขึ้นและอาจเป็นสาเหตุของมัน IE ถ้าเราเลือกรูปแบบที่เข้มงวดการตอบสนองอาจเป็น400 - DELETE failed on ID 1221 not foundไปได้ หากเราเลือกรุ่น 'ดี' อาจเป็นได้207 - {message:"failed, some ids not deleted", failedids:{1221, 23432, 1224}}(แก้ตัวการจัดรูปแบบ json ที่ไม่ดีของฉัน)

โชคดี!

หนึ่งควรจะเข้มงวดและอนุญาต

โดยปกติโหลดจำนวนมากจะถูกแบ่งออกเป็น 2 ขั้นตอน:

• การตรวจสอบ
• กำลังโหลด

ในระหว่างขั้นตอนการตรวจสอบความถูกต้องทุกระเบียนจะถูกตรวจสอบอย่างเคร่งครัดเพื่อให้แน่ใจว่าเป็นไปตามข้อกำหนดของข้อมูลจำเพาะ หนึ่งสามารถตรวจสอบ 10s จาก 1,000s ของบันทึกในเวลาเพียงไม่กี่วินาที ระเบียนที่ถูกต้องจะอยู่ในไฟล์ใหม่ที่จะโหลดหนึ่งรายการที่ไม่ถูกต้องจะถูกตั้งค่าสถานะและลบออกและมักจะใส่ในไฟล์แยกต่างหาก (ไฟล์ข้าม) จากนั้นระบบจะส่งการแจ้งเตือนไปยังระเบียนที่ไม่ผ่านการตรวจสอบเพื่อให้สามารถตรวจสอบและวินิจฉัยเพื่อแก้ไขปัญหา

เมื่อข้อมูลได้รับการตรวจสอบแล้วมันจะถูกโหลด โดยปกติจะโหลดเป็นชุดถ้ามันมีขนาดใหญ่พอที่จะหลีกเลี่ยงการทำธุรกรรมที่ยาวนานหรือหากมีความล้มเหลวมันจะง่ายต่อการกู้คืน ขนาดแบตช์ขึ้นอยู่กับขนาดของชุดข้อมูล หากมีเพียง 1,000 เรคคอร์ดเพียงไม่กี่ชุดเดียวก็จะโอเค ที่นี่คุณสามารถอนุญาตด้วยความล้มเหลว แต่อาจต้องการตั้งค่าขีด จำกัด แบตช์ล้มเหลวเพื่อหยุดการดำเนินการทั้งหมด บางทีถ้า [N] แบตช์ล้มเหลวก็จะหยุดการดำเนินการทั้งหมด (ถ้าเซิร์ฟเวอร์ไม่ทำงานหรือสิ่งที่คล้ายกัน) โดยปกติแล้วจะไม่มีความล้มเหลวในจุดนี้เนื่องจากข้อมูลได้รับการตรวจสอบแล้ว แต่ถ้าเกิดจากปัญหาสิ่งแวดล้อมหรืออื่น ๆ เพียงโหลดแบตช์ที่ล้มเหลว ทำให้การกู้คืนง่ายขึ้นเล็กน้อย

ความล้มเหลวเดียวควรล้มเหลวในการดำเนินการเป็นกลุ่ม?

ไม่มีคำตอบที่ยอมรับได้สำหรับเรื่องนี้ ความต้องการและผลที่ตามมาของผู้ใช้จะต้องได้รับการตรวจสอบและประเมินการแลกเปลี่ยน OP ให้ข้อมูลบางอย่างที่จำเป็น แต่นี่คือวิธีที่ฉันจะดำเนินการต่อ:

คำถามที่ 1 : 'ผู้ใช้จะเกิดอะไรขึ้นหากการลบแต่ละรายการล้มเหลว'

คำตอบควรขับเคลื่อนส่วนที่เหลือของพฤติกรรมการออกแบบ / การใช้งาน

ถ้าตามที่ระบุในประเภท OP ผู้ใช้จะสังเกตเห็นข้อยกเว้นและเปิดตั๋วแจ้งเหตุ แต่ไม่ได้รับผลกระทบอย่างอื่น (รายการที่ไม่ถูกลบจะไม่ส่งผลกระทบต่องานที่ตามมา) ดังนั้นฉันจะอนุญาตด้วยการแจ้งเตือนอัตโนมัติ ถึงคุณ.

หากการลบที่ล้มเหลวจำเป็นต้องได้รับการแก้ไขก่อนที่ผู้ใช้จะสามารถดำเนินการต่อได้แสดงว่าเข้มงวดกว่า

การให้ตัวเลือกแก่ผู้ใช้ (เช่นการตั้งค่าสถานะการเพิกเฉยต่อความล้มเหลวด้วยการเข้มงวดหรือการอนุญาตเป็นค่าเริ่มต้น) อาจเป็นวิธีที่เป็นมิตรกับผู้ใช้มากที่สุด

คำถามที่ 2 : 'จะมีปัญหาการเชื่อมโยงข้อมูล / ความสอดคล้องใด ๆ หรือไม่หากงานที่ตามมาจะดำเนินการกับรายการที่ไม่ถูกลบยังอยู่ในแหล่งข้อมูลหรือไม่'

อีกครั้งคำตอบจะผลักดันการออกแบบ / พฤติกรรมที่ดีที่สุด ใช่ -> เข้มงวด, ไม่ -> อนุญาต, อาจ -> เข้มงวดหรือเลือกผู้ใช้ (โดยเฉพาะถ้าผู้ใช้สามารถขึ้นอยู่กับการกำหนดผลที่ถูกต้อง)

ฉันคิดว่าสิ่งนี้ขึ้นอยู่กับว่าคุณต้องการความยืดหยุ่นหรือไม่ หากคุณไม่ต้องการมี ID จำนวนมากก็ไม่ควรทำอะไรมากเกินไป หากคุณตั้งใจจะมี ID เป็นล้านหรือดีกว่ายังไม่แน่ใจว่าจะไม่เกิดขึ้นอย่างแน่นอนคุณสามารถใช้เวลาหนึ่งชั่วโมงในการลบ ID เพียงเพื่อให้รีเซ็ตอย่างสมบูรณ์เนื่องจาก 1 ID ไม่ถูกต้อง

ฉันจะบอกว่าจุดสำคัญจุดหนึ่งที่นี่คือความหมายสำหรับการลบข้อมูลจำนวนมาก

รหัสเหล่านี้เกี่ยวข้องกับเหตุผลอย่างใดอย่างหนึ่งหรือเป็นเพียงความสะดวกสบาย / ประสิทธิภาพ - การจัดกลุ่มแบทช์ของสิ่งเหล่านี้หรือไม่

strictในกรณีของการอย่างใดแม้หลวมเชื่อมต่อผมต้องการไปสำหรับ หากเป็นเพียงโหมดแบทช์ (เช่นผู้ใช้คลิก "บันทึก" สำหรับนาทีสุดท้ายของการทำงานและจากนั้นจะส่งแบตช์) จากนั้นฉันจะไปหาpermissiveรุ่น

ดังที่คำตอบอื่น ๆ ระบุไว้: ไม่ว่าในกรณีใด ๆ จะบอกผู้ใช้ว่า "เกิดอะไรขึ้น"