Có nên một thất bại duy nhất thất bại một hoạt động hàng loạt?


11

Trong API tôi đang làm việc có một thao tác xóa hàng loạt chấp nhận một mảng ID:

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

Tôi được tự do thực hiện thao tác xóa khi tôi thấy phù hợp, vì vậy tôi quyết định thực hiện toàn bộ giao dịch: đó là, nếu một ID duy nhất không hợp lệ, toàn bộ yêu cầu không thành công. Tôi sẽ gọi đây là chế độ nghiêm ngặt .

try{
savepoint = conn.setSavepoint();

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

conn.commit();
}

Cách thay thế (được triển khai ở nơi khác trong bộ phần mềm của chúng tôi) là làm những gì chúng ta có thể trong phần phụ trợ và báo cáo các lỗi trong một mảng. Đó là một phần của phần mềm xử lý ít yêu cầu hơn nên phản hồi cuối cùng không phải là một mảng khổng lồ ... trên lý thuyết.


Một lỗi gần đây xảy ra trong một máy chủ nghèo tài nguyên khiến tôi phải xem lại mã và bây giờ tôi đang đặt câu hỏi cho quyết định ban đầu của mình - nhưng lần này tôi được thúc đẩy nhiều hơn bởi nhu cầu kinh doanh hơn là các thực tiễn tốt nhất. Ví dụ, nếu tôi thất bại toàn bộ yêu cầu, người dùng sẽ phải thử lại trong khi nếu một số mục bị xóa, người dùng có thể hoàn thành hành động và sau đó yêu cầu quản trị viên thực hiện phần còn lại (trong khi tôi khắc phục lỗi !). Đây sẽ là chế độ cho phép .

Tôi đã cố gắng tìm kiếm trực tuyến một số hướng dẫn về vấn đề này nhưng tôi đã ra về tay không. Vì vậy, tôi đến với bạn: Điều gì được mong đợi nhất bởi các hoạt động hàng loạt có tính chất này? Tôi nên gắn bó với nghiêm ngặt hơn, hay tôi nên dễ dãi hơn?


9
Nó phụ thuộc. Chi phí để có một cái gì đó không bị xóa khi cần là gì? (Chi phí được xác định là dữ liệu xấu, đau đầu, hành vi không mong muốn, thời gian quản trị viên phải sửa nó, v.v.) Điều đó có được chấp nhận không? Nếu bạn có thể sống với hậu quả của việc không thất bại tất cả mọi thứ, hãy đi cho nó. Nếu nó sẽ gây ra quá nhiều vấn đề, đừng. Bạn biết phần mềm của mình và hậu quả, vì vậy bạn sẽ phải thực hiện một cuộc gọi phán xét.
Becuzz

1
@Becuzz Chi phí sẽ là người dùng nhận thấy một hoặc hai thức ăn thừa và mở một vé về điều đó; tình hình hiện tại là "omg xóa bị hỏng". May mắn thay, người dùng đang ở hành lang, vì vậy lần này không có quá nhiều vấn đề. Vấn đề là, tôi thích làm điều đúng bất cứ khi nào có thể, và với một cơ sở mã hơn 10 năm tuổi, Chúa biết một số điều có thể được thực hiện một cách chính xác
rath

Tôi nghĩ điều này cũng phụ thuộc vào việc bạn có muốn mở rộng hay không. Nếu bạn không có nhiều ID, thì điều đó không thành vấn đề. Nếu bạn dự định có một triệu ID, hoặc tốt hơn nữa, không chắc chắn điều đó sẽ không xảy ra, thì bạn có thể mất một giờ để xóa ID chỉ để đặt lại hoàn toàn do 1 ID không hợp lệ.
imnota4

1
@ imnota4 Một điểm tuyệt vời tôi đã không xem xét. Giao diện người dùng hạn chế yêu cầu tối đa khoảng 250, nhưng phụ trợ không bị hạn chế. Tôi có thể yêu cầu bạn đăng lại nhận xét của bạn như một câu trả lời không?
Rath

1
Chế độ cho phép cũng giúp Quản trị viên dễ dàng hơn vì họ không cần phải tạo lại thất bại với tất cả các ngăn xếp của id. Nó cũng có thể hữu ích để thông báo trong phản hồi nguyên nhân của từng lỗi. Nhìn vào nguyên nhân, người dùng cuối cùng có thể giải quyết nó mà không có vé "omg xóa bị hỏng".
Laiv

Câu trả lời:


9

Bạn có thể thực hiện phiên bản 'nghiêm ngặt' hoặc 'đẹp' của điểm cuối xóa, nhưng bạn cần nói rõ cho người dùng biết chuyện gì đã xảy ra.

Chúng tôi đang thực hiện một hành động xóa với điểm cuối này. Có khả năng DELETE /resource/bulk/hoặc một cái gì đó tương tự. Tôi không kén chọn. Điều quan trọng ở đây là không có vấn đề gì nếu bạn quyết định nghiêm khắc hay tốt đẹp, bạn cần báo cáo lại chính xác những gì đã xảy ra.

Ví dụ: API tôi đã làm việc có DELETE /v1/student/điểm cuối chấp nhận ID hàng loạt. Chúng tôi thường xuyên gửi yêu cầu trong quá trình thử nghiệm, nhận 200phản hồi và cho rằng mọi thứ đều ổn, chỉ sau đó mọi người trong danh sách đều ở trong cơ sở dữ liệu vẫn còn (được đặt thành không hoạt động) hoặc không thực sự bị xóa do lỗi. làm rối tung các cuộc gọi trong tương lai GET /v1/studentvì chúng tôi đã lấy lại dữ liệu mà chúng tôi không mong đợi.

Giải pháp cho vấn đề này xuất hiện trong một bản cập nhật sau đó đã thêm phần thân vào phản hồi với các id không bị xóa. Đây là - theo hiểu biết của tôi - một loại thực hành tốt nhất.

Điểm mấu chốt, bất kể bạn làm gì, hãy đảm bảo rằng bạn cung cấp một cách để cho người dùng cuối biết điều gì đang xảy ra và có thể tại sao nó lại diễn ra. IE, nếu chúng tôi chọn một định dạng nghiêm ngặt, phản hồi có thể là 400 - DELETE failed on ID 1221 not found. Nếu chúng tôi chọn một phiên bản 'đẹp', thì đó có thể là 207 - {message:"failed, some ids not deleted", failedids:{1221, 23432, 1224}}(xin lỗi định dạng json kém của tôi).

Chúc may mắn!


6
207 Multi-Statuscó thể phù hợp với phản ứng thất bại một phần
Richard Tingle

1
CHÚNG TÔI ĐI! Tôi thực sự không thể nhớ nó! Tôi sẽ tiếp tục và cập nhật câu trả lời với điều đó, vì điều đó thực sự đạt tiêu chuẩn.
Adam Wells

2

Một người nên nghiêm khắc và cho phép.

Thông thường, tải số lượng lớn được chia thành 2 giai đoạn:

  • Thẩm định
  • Đang tải

Trong giai đoạn xác nhận, mọi bản ghi đều được xem xét nghiêm ngặt để đảm bảo rằng nó đáp ứng các yêu cầu của thông số kỹ thuật dữ liệu. Người ta có thể dễ dàng kiểm tra 10 trong số 1000 hồ sơ chỉ trong vài giây. Các bản ghi hợp lệ được đặt trong một tệp mới sẽ được tải, (các) tệp không hợp lệ được gắn cờ và xóa và thường được đặt trong một tệp riêng (bỏ qua tệp). Thông báo sau đó được gửi đi trong hồ sơ xác nhận không thành công để họ có thể được kiểm tra và chẩn đoán cho mục đích khắc phục sự cố.

Khi dữ liệu đã được xác thực, nó sẽ được tải. Thông thường, nó được tải theo đợt nếu nó đủ lớn để tránh các giao dịch chạy dài hoặc nếu có lỗi sẽ dễ dàng phục hồi hơn. Kích thước hàng loạt phụ thuộc vào mức độ lớn của tập dữ liệu. Nếu một chỉ có vài 1000 bản ghi, một lô sẽ ổn. Ở đây bạn có thể được cho phép một chút với các thất bại, nhưng người ta có thể muốn đặt ngưỡng lô thất bại để dừng toàn bộ hoạt động. Có thể nếu các lô [N] thất bại, người ta sẽ dừng toàn bộ hoạt động (nếu máy chủ ngừng hoạt động hoặc một cái gì đó tương tự). Thông thường, không có thất bại tại thời điểm này vì dữ liệu đã được xác thực, nhưng nếu có vấn đề về môi trường hoặc khác, chỉ cần tải lại (các) lô không thành công. Điều này làm cho việc phục hồi dễ dàng hơn một chút.


Tôi không xác thực ID dựa trên các giá trị DB, tôi chỉ cố gắng xóa chúng và xem điều đó diễn ra như thế nào, hoặc sẽ mất mãi mãi. Hủy bỏ sau N thất bại có vẻ là một gợi ý rất hợp lý, +1
rath

2

Có nên một thất bại duy nhất thất bại một hoạt động hàng loạt?

Không có câu trả lời chính tắc cho vấn đề này. Nhu cầu và hậu quả đối với người dùng cần được kiểm tra và đánh giá sự đánh đổi. OP đã đưa ra một số thông tin cần thiết, nhưng đây là cách tôi sẽ tiến hành:

Câu hỏi 1 : 'Hậu quả đối với người dùng là gì nếu việc xóa cá nhân không thành công?'

Câu trả lời sẽ thúc đẩy phần còn lại của hành vi thiết kế / thực hiện.

Nếu, như loại OP đã nêu, chỉ đơn giản là người dùng nhận thấy ngoại lệ và mở một vé rắc rối, nhưng nếu không bị ảnh hưởng (các mục không bị xóa không ảnh hưởng đến các tác vụ tiếp theo), thì tôi sẽ đi kèm với thông báo tự động để bạn

Nếu việc xóa không thành công cần phải được giải quyết trước khi người dùng có thể tiến hành, thì rõ ràng nghiêm ngặt hơn.

Cung cấp cho người dùng tùy chọn (ví dụ, về cơ bản là cờ bỏ qua lỗi với mức độ nghiêm ngặt hoặc cho phép như mặc định) có thể là cách tiếp cận thân thiện với người dùng nhất.

Câu hỏi 2 : 'Sẽ có bất kỳ vấn đề kết hợp / thống nhất dữ liệu nào nếu các tác vụ tiếp theo được thực hiện với các mục không bị xóa vẫn còn trong kho lưu trữ dữ liệu?'

Một lần nữa, câu trả lời sẽ thúc đẩy thiết kế / hành vi tốt nhất. Có -> Nghiêm, Không -> Cho phép, Có thể -> Nghiêm hoặc Người dùng đã chọn (đặc biệt nếu người dùng có thể phụ thuộc vào để xác định chính xác hậu quả).


0

Tôi nghĩ điều này phụ thuộc vào việc bạn có muốn mở rộng hay không. Nếu bạn không có nhiều ID, thì điều đó không thành vấn đề. Nếu bạn dự định có một triệu ID, hoặc tốt hơn nữa, không chắc chắn điều đó sẽ không xảy ra, thì bạn có thể mất một giờ để xóa ID chỉ để đặt lại hoàn toàn do 1 ID không hợp lệ.


-1

Tôi muốn nói một điểm quan trọng ở đây là ý nghĩa của việc hàng loạt nội dung bị xóa.

Những ID này bằng cách nào đó có liên quan về mặt logic, hay nó chỉ là một sự tiện lợi / hiệu suất - nhóm các nhóm này?

Trong trường hợp bằng cách nào đó, thậm chí lỏng lẻo, kết nối, tôi sẽ đi strict. Nếu đó chỉ là chế độ hàng loạt (ví dụ: người dùng nhấp vào "lưu" cho những phút làm việc cuối cùng của anh ấy và chỉ sau đó là lô được truyền) thì tôi sẽ dùng permissivephiên bản.

Như câu trả lời khác nêu: Trong mọi trường hợp, hãy nói với "người dùng" chính xác những gì đã xảy ra.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.