cassava-conduit-0.6.2: Conduit interface for cassava package
Copyright(C) 2014
LicenseBSD-style (see the file etc/LICENSE.md)
MaintainerDom De Re
Safe HaskellSafe-Inferred
LanguageHaskell2010

Data.Csv.Conduit

Description

Conduit interface for cassava

Synopsis

Types

data CsvStreamHaltParseError Source #

When you want to include errors in the stream, this error type represents errors that halt the stream. They do not appear inside the conduit and will instead get returned from running the conduit.

Constructors

HaltingCsvParseError ByteString Text

the remaining bytestring that was read in but not parsed yet, and the stringy error msg describing the fail.

data CsvStreamRecordParseError Source #

When you want to include errors in the stream, these are the errors that can be included in the stream, they are usually problems restricted to individual records, and streaming can resume from the next record you just have to decide on something sensible to do with the per record errors.

Constructors

CsvStreamRecordParseError Text

The stringy error describing why this record could not be parsed.

Conduits

fromCsv :: (FromRecord a, MonadError CsvParseError m) => DecodeOptions -> HasHeader -> ConduitT ByteString a m () Source #

Streams parsed records, Errors are not received in the stream but instead after the pipeline is executed, If you want to handle errors as they come and resume, see fromCsvStreamError

fromCsvLiftError :: (FromRecord a, MonadError e m) => (CsvParseError -> e) -> DecodeOptions -> HasHeader -> ConduitT ByteString a m () Source #

Sometimes your pipeline will involve an error type other than CsvParseError, in which case if you provide a function to project it into your custom error type, you can use this instead of fromCsv

fromNamedCsv :: (FromNamedRecord a, MonadError CsvParseError m) => DecodeOptions -> ConduitT ByteString a m () Source #

Parses an instance of FromNamedRecord, this conduit drops the Header

Errors are not seen in the pipeline but rather at the end after executing the pipeline, if you want to handle the errors as they occur, try fromNamedCsvStreamError instead.

fromNamedCsvLiftError :: (FromNamedRecord a, MonadError e m) => (CsvParseError -> e) -> DecodeOptions -> ConduitT ByteString a m () Source #

Sometimes your pipeline will involve an error type other than CsvParseError, in which case if you provide a function to project it into your custom error type, you can use this instead of fromCsv

fromCsvStreamError :: (FromRecord a, MonadError e m) => DecodeOptions -> HasHeader -> (CsvStreamHaltParseError -> e) -> ConduitT ByteString (Either CsvStreamRecordParseError a) m () Source #

Same as fromCsv but allows for errors to be handled in the pipeline instead

fromCsvStreamErrorNoThrow :: (Monad m, FromRecord a) => DecodeOptions -> HasHeader -> ConduitT ByteString (Either (Either CsvStreamHaltParseError CsvStreamRecordParseError) a) m () Source #

Same as fromCsvStreamError but allows for halting errors to be handled by the pipeline as well.

fromNamedCsvStreamError :: (FromNamedRecord a, MonadError e m) => DecodeOptions -> (CsvStreamHaltParseError -> e) -> ConduitT ByteString (Either CsvStreamRecordParseError a) m () Source #

Like fromNamedCsvStream but allows for errors to be handled in the pipeline itself.

toCsv :: (Monad m, ToRecord a) => EncodeOptions -> ConduitT a ByteString m () Source #

Streams from csv to text, does not create headers...