You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
help:"Make sure the URL is valid and you are allowed to access the file. Alternatively set the configuration's presample or load the file in a data blob and use the reader's data initializer.",
221
221
userInfo:["File URL": url])
222
222
}
223
+
/// Error raised when a record is fetched, but there are header names which has the same hash value (i.e. they have the same name).
Copy file name to clipboardExpand all lines: sources/Codable/Decodable/DecodingStrategy.swift
+17-9Lines changed: 17 additions & 9 deletions
Original file line number
Diff line number
Diff line change
@@ -35,18 +35,26 @@ extension Strategy {
35
35
case custom((_ decoder:Decoder)throws->Data)
36
36
}
37
37
38
-
/// Strategy indicating how many rows are cached for reuse by the decoder.
38
+
/// Indication of how many rows are cached for reuse by the decoder.
39
39
///
40
-
/// The `Decodable` protocol allows CSV rows to be decoded in random-order through the keyed containers. For example, a user can ask for a row at position 24 and then ask for the CSV row at index 1.
41
-
/// Since it is impossible to foresee how the user will decode the rows, this library allows the user to set the buffering mechanism.
40
+
/// CSV decoding is an inherently sequential operation; i.e. row 2 must be decoded after row 1. This due to the string encoding, the field/row delimiter usage, and by not setting the underlying row width.
41
+
/// On the other hand, the `Decodable` protocol allows CSV rows to be decoded in random-order through the keyed containers. For example, a user can ask for a row at position 24 and then ask for the CSV row at index 3.
42
42
///
43
-
/// Setting the buffering strategy lets you tweak the memory usage and whether an error will be thrown when previous rows are requested:
44
-
/// - `keepAll` will impose no restrictions and will make the decoder cache every decoded row. Setting this strategy will double the memory usage, but the user is free to request rows in any order.
45
-
/// - `ordered` discard decoded rows after usage, only keeping records when a jump forward have been requested through a keyed container.
46
-
publicenumBuffering{
43
+
/// A buffer is used to marry the sequential needs of the CSV decoder and `Decodable`'s *random* nature. This buffer stores all decoded CSV rows (starts with none and gets filled as more rows are being decoded).
44
+
/// The `DecodingBuffer` strategy gives you the option to control the buffer's memory usage and whether rows are being discarded after being decoded.
45
+
publicenumDecodingBuffer{
47
46
/// All decoded CSV rows are cached.
47
+
/// Forward/Backwards decoding jumps are allowed. A row that has been previously decoded can be decoded again.
48
+
///
49
+
/// Setting this strategy will double the memory usage, but the user is free to request rows in any order.
48
50
case keepAll
49
-
/// Rows are only cached when there are holes between the decoded row indices.
50
-
// case ordered
51
+
/// Only CSV rows that have been decoded but not requested by the user are being kept in memory.
52
+
/// Forward/Backwards decoding jumps are allowed. However, previously requested rows cannot be requested again or an error will be thrown.
53
+
///
54
+
/// This strategy will massively reduce the memory usage, but it will throw an error if a CSV row that was previously decoded is requested from a keyed container.
55
+
case unfulfilled
56
+
/// No rows are kept in memory (except for the CSV row being decoded at the moment)
57
+
/// Forward jumps are allowed, but the rows in-between the jump cannot be decoded.
0 commit comments