Questo dipende dal modo in cui il CSV viene creato, mantenuto o risolto in caso di errori e da come i dati importati saranno elaborati in seguito.
Iniziamo con la domanda "tutto o niente" e "rifiuta solo quelli cattivi": per scartare alcune righe e accettare solo una parte di esse ha senso solo
-
se il sottoinsieme importato può essere elaborato senza le righe scartate in modo significativo
-
se l'utente può correggere facilmente le righe rifiutate e successivamente importarle di nuovo separatamente
Se tuttavia non è possibile un'elaborazione significativa senza il set completo di righe, è necessario respingerlo completamente. La stessa cosa è una buona idea se si è sicuri che gli utenti creino sempre il CSV "nel suo insieme" (magari usando uno strumento automatico) e, in caso di errori, possono facilmente ricreare di nuovo il CSV fisso completo.
Alla domanda su come dovrebbero apparire le informazioni sull'errore: una specifica dei record rifiutati (e il motivo per cui sono stati respinti) ha senso se l'utente può effettivamente elaborare questa lista di errori in modo ragionevole. Se questo è il caso, ma il log degli errori può diventare molto lungo, si consideri di restituirlo sotto forma di un file di registro. Se sai per certo che gli utenti hanno bisogno solo di alcuni esempi di ciò che è andato storto, per correggere il processo di creazione CSV (e non per correggere le singole righe CSV una per una), allora ha senso limitare le informazioni di errore a, per esempio, qualcosa come i primi 10 o 50 messaggi di errore.
TLDR; non esiste una "taglia unica", è necessario comprendere i casi d'uso nella catena prima e dopo l'importazione, solo dopo si può prendere una decisione sensata.