Η μαζική αλλαγή 5.000 πελατών σε νέο owner ή η δημοσίευση εκατοντάδων προϊόντων εξοικονομεί ώρες. Το ίδιο κουμπί μπορεί όμως να προκαλέσει εκτεταμένη ζημιά αν το φίλτρο είναι λάθος, αν ο χρήστης παρερμηνεύσει το scope ή αν η διαδικασία σταματήσει στη μέση.
Οι bulk actions χρειάζονται διαφορετικό σχεδιασμό από ένα απλό update. Πρέπει να δείχνουν τι ακριβώς θα επηρεαστεί, να ελέγχουν permission ανά record και να έχουν στρατηγική atomicity, retry και recovery.
Το selection model πρέπει να είναι ξεκάθαρο
Υπάρχουν δύο βασικά scopes:
- ρητή επιλογή συγκεκριμένων IDs
- επιλογή «όλων των αποτελεσμάτων» ενός αποθηκευμένου query
Το δεύτερο δεν πρέπει να μετατραπεί σιωπηλά σε λίστα των 50 rows που φαίνονται στην τρέχουσα σελίδα. Το UI δηλώνει «Επιλέχθηκαν 3.482 εγγραφές που ταιριάζουν στο φίλτρο» και προσφέρει link για έλεγχο του φίλτρου.
Στο backend αποθηκεύεται είτε snapshot IDs είτε immutable query definition με timestamp. Αν τα δεδομένα αλλάζουν γρήγορα, αποφασίζεται αν η action εφαρμόζεται στο snapshot ή σε ό,τι ταιριάζει κατά την εκτέλεση. Η επιλογή πρέπει να είναι προβλέψιμη.
Preview ή dry run πριν από την επιβεβαίωση
Πριν το write, ο server υπολογίζει count, επιπτώσεις και εξαιρέσεις. Το preview μπορεί να δείχνει:
- πόσα records θα αλλάξουν
- πόσα δεν επιτρέπονται λόγω permissions
- sample πριν και μετά
- conflicts ή invalid states
- downstream effects, όπως emails ή integrations
- αν η ενέργεια μπορεί να αναιρεθεί
Για αλλαγή owner, το preview δείχνει προηγούμενη και νέα ανάθεση. Για διαγραφή, δείχνει dependencies και retention. Η επιβεβαίωση επαναλαμβάνει τον ακριβή αριθμό και χρησιμοποιεί συγκεκριμένο command label, όχι γενικό «OK».
Permissions ανά εγγραφή
Το ότι ο χρήστης βλέπει τη λίστα δεν σημαίνει ότι επιτρέπεται να αλλάξει κάθε row. Το backend ελέγχει authorization για κάθε record ή για scope που αποδεικνύεται ισοδύναμο. Δεν εμπιστεύεται IDs από τον browser.
Η πολιτική μπορεί να είναι all-or-nothing ή partial success. Σε ευαίσθητη ενέργεια, αν ένα record δεν επιτρέπεται, απορρίπτεται όλη η action. Σε χαμηλότερου ρίσκου update, τα επιτρεπόμενα αλλάζουν και παράγεται report για τα αποτυχημένα. Το UI γνωρίζει εκ των προτέρων ποια πολιτική ισχύει.
Μία transaction ή background job
Για μικρό σύνολο στην ίδια βάση, μια database transaction μπορεί να προσφέρει atomicity: όλες οι αλλαγές εφαρμόζονται ή καμία. Η PostgreSQL τεκμηρίωση περιγράφει τις transactions ως all-or-nothing operation, ενώ τα savepoints επιτρέπουν rollback μέρους της εργασίας μέσα σε transaction.
Για δεκάδες χιλιάδες records ή εξωτερικά APIs, μία μεγάλη transaction μπορεί να κρατά locks και να αποτυγχάνει αργά. Τότε χρησιμοποιείται background job με chunks, checkpoints και idempotent processing. Κάθε row έχει result status και η συνολική εργασία εμφανίζει progress.
Το job δεν θεωρείται επιτυχές επειδή μπήκε στην queue. Ο χρήστης λαμβάνει completion report με changed, skipped και failed counts.
Side effects και emails
Μια bulk αλλαγή μπορεί να ενεργοποιεί automations. Αν 5.000 status updates στείλουν 5.000 emails κατά λάθος, η διόρθωση δεδομένων δεν ανακαλεί τα μηνύματα. Για αυτό το preview δηλώνει side effects και η action μπορεί να προσφέρει επιλογή suppress notifications μόνο σε εξουσιοδοτημένους ρόλους.
Τα events δημοσιεύονται με stable operation ID. Οι consumers αποφεύγουν διπλή επεξεργασία σε retry. Αν η bulk action αφορά import ή maintenance, μπορεί να παραχθεί ένα aggregate event αντί για χιλιάδες ανεξέλεγκτες ειδοποιήσεις, εφόσον το domain το επιτρέπει.
Undo: αντιστροφή, όχι μαγικό κουμπί
Το undo είναι δυνατό όταν καταγράφεται το προηγούμενο value ανά record και η αντίστροφη ενέργεια παραμένει έγκυρη. Για παράδειγμα, αλλαγή tag ή owner μπορεί να αντιστραφεί. Η αποστολή email, εξωτερική πληρωμή ή οριστική διαγραφή δεν αναιρείται απλά.
Το undo έχει χρονικό παράθυρο και permission check. Επίσης ελέγχει αν το record άλλαξε ξανά μετά τη bulk operation. Δεν πρέπει να επαναφέρει παλιά τιμή πάνω από νεότερη ανθρώπινη αλλαγή. Σε αυτή την περίπτωση εμφανίζει conflict ή παραλείπει το record.
Για destructive actions προτιμάται soft delete, quarantine ή staged deletion με δεύτερη έγκριση. Η οριστική εκτέλεση γίνεται αργότερα από job και καταγράφεται.
Audit trail και operation entity
Κάθε bulk action δημιουργεί operation record με actor, timestamp, action type, selection definition, input parameters, preview count και status. Τα αποτελέσματα ανά row μπορούν να αποθηκεύονται σε child records ή artifact.
Αυτό επιτρέπει απάντηση στις ερωτήσεις «ποιος άλλαξε αυτά τα προϊόντα;», «ποιο φίλτρο χρησιμοποίησε;» και «ποια rows απέτυχαν;». Τα sensitive values δεν χρειάζεται να αντιγράφονται άκριτα στο log. Αποθηκεύονται όσα χρειάζονται για έλεγχο και recovery.
Concurrency και stale preview
Μεταξύ preview και confirm μπορεί να αλλάξουν δεδομένα. Το confirm στέλνει preview token με version ή expiration. Ο server επανελέγχει count και critical conditions. Αν η απόκλιση είναι σημαντική, ζητά νέο preview αντί να εκτελέσει διαφορετική action από αυτή που είδε ο χρήστης.
Σε updates χρησιμοποιούνται optimistic version checks. Τα conflicts αναφέρονται ξεχωριστά και δεν αντικαθίστανται σιωπηλά.
Πώς το υλοποιεί η Ai Foundry
Στην Ai Foundry αντιμετωπίζουμε κάθε bulk action ως ελεγχόμενη operation. Σχεδιάζουμε σαφές selection scope, server-side preview, permission checks και confirmation που περιγράφει ακριβώς την επίπτωση. Για μικρές αλλαγές χρησιμοποιούμε atomic transactions, ενώ για μεγάλες εργασίες queues, chunks, checkpoints και completion reports.
Προσθέτουμε audit trail, idempotency και undo μόνο όπου υπάρχει ασφαλής αντίστροφη λειτουργία. Ελέγχουμε stale previews, retries και partial failures με automated tests. Έτσι τα admin panels και CRM της Ai Foundry επιτρέπουν στην ομάδα να δουλεύει γρήγορα χωρίς ένα ασαφές checkbox να μετατρέπεται σε εκτεταμένο λάθος.
Συμπέρασμα
Η ασφάλεια μιας bulk action βρίσκεται στο preview, στο scope και στη δυνατότητα recovery. Με permissions ανά record, σωστή atomicity και operation history, η μαζική επεξεργασία γίνεται εργαλείο παραγωγικότητας αντί για ρίσκο.