Take rows by position
Read rows of planned splits by position, as an Arrow IPC stream in request order: each take's rows in the order of its positions, a repeated position's row again, and the takes one after another. Each split's rows are read in one pass, so positions that share storage share its reads. Every batch ends with the two dictionary columns of read_scan: scandal.next_row holds how many of the request's positions, counted across its takes, the batches so far delivered, so a client resumes by sending the positions after them; scandal.metrics holds the counters of every split read, on a last batch of no rows, when the scan collects them. A position past a split's rows fails the request before any output. A failure after the stream starts ends it without the Arrow end-of-stream marker.
bearerAuthAuthorizationBearer <token>application/json- body
Takes of a scan's rows, read in order. The scan's columns or projection, batchRows and collectMetrics apply; a scan with a filter, limit or emit is invalid. A request takes at most 65,536 positions from at most 256 splits.
scan*A read of one Table version, sent whole with every plan and read request. columns selects top-level columns, or all of them when absent; projection computes the output columns instead. A filter clause that the service cannot enforce exactly fails the scan before any rows are read. limit caps the rows each split returns, in stored order. An emit returns a top-k or aggregates of the output rows instead of the rows themselves. rowRange selects half-open stored positions in this exact version, before filtering and deletion removal, concatenating fragments in stored order. Positions are not stable across rewrites. Empty ranges return no rows; reversed ranges are invalid. rowIdColumn adds a last output column of that name holding each row's row ID: the Table's stable identity of the row, a uint64 that survives rewrites and compaction and is never reused. rowIds keeps only rows whose row IDs fall in its ranges: planning prunes files whose row IDs cannot match, and reads enforce it exactly. A top-k can return and order by the row ID column. Aggregates take no rowIdColumn.
storage?|nulltakes*array<>Success
response?fileapplication/vnd.apache.arrow.streambinarycurl -X POST 'https://scandal.spiraldb.dev/scans/take' \ -H 'Content-Type: application/json' \ -d '{ "scan": { "table": { "resourceId": "026d60bb-63a8-407e-bf67-01dcfc6022e6", "versionId": "14707576-2549-4848-82ed-f68f8a1b47c7" } }, "takes": [ { "positions": [ "string" ], "split": { "fragment": "string", "rows": { "end": "string", "start": "string" } } } ]}'"string"