feat(client): add queryTable for column-aware query results - #51
Merged
Conversation
The JSON format sorts keys alphabetically and omits any column that is NULL for a row, so column order is unrecoverable and row objects differ in shape. CSV carries the real column order and every column for every row. No response format carries column types, so values stay raw strings rather than being guessed at.
AayushMainali-Github
added
type: feature
github-actions
Bot
added
area: testing
2.4.3 returns the header row for an empty result; 2.4.1 returns an empty body. The ping string cannot distinguish them, since 2.4.1 reports itself as 2.4.0, so the test accepts both and the docs no longer promise columns below 2.4.3.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds
client.queryTable(), returning a result's columns alongside its rows.What probing the server changed about this issue
The issue asked for "column metadata and typed row helpers". The server only supports half of that, so this delivers the half that is real and documents why the rest is not.
Accept: application/json, whichquery()uses, turned out to lose two things:SELECT v, cityreturns{"city": ..., "v": ...}, so column order cannot be recovered from the response.SELECT city, v, nover two rows returns[{"city":"Pokhara","n":7,"v":1.5},{"city":"Lalitpur","v":2.5}]. The second row has nonkey at all, so row objects differ in shape and a typedTpromisingn: numberis simply wrong.Accept: application/csvcarries the column names in their true order, emits every column for every row, and still returns the header row when nothing matched. That is whatqueryTable()uses.No response format carries column types, so "typed row helpers" cannot be built on anything but guesswork. Values come back as raw strings and the caller converts what it needs. Guessing wrong on a large integer or a timestamp is worse than an honest string.
One ambiguity is unavoidable and documented: CSV renders both NULL and an empty string as an empty field, so the two cannot be told apart.
Implementation
A small hand-written RFC 4180 parser in
src/csv/, rather than a dependency: the grammar is tiny, the input comes from one known producer, and a parser is easier to audit than another supply-chain entry in a client whose only job is talking to one server. It handles quoted fields, doubled quotes, embedded commas and newlines, CRLF and bare CR, and empty leading, middle, and trailing fields.query()is untouched. This is an addition, not a replacement: JSON remains the more convenient option when you know the columns and none of them are nullable.Also exports the
Compressiontype from the package root. It was added as a client option in 0.2.0 but was never importable, so anyone annotating a variable with it could not.Testing
52 new unit tests, taking the suite from 295 to 347. 22 cover the CSV parser directly, including the doubled-quote form CnosDB actually emits.
Four integration tests confirm the behaviour against a live server rather than against my reading of it: column order survives, an empty result still reports its columns, a NULL stays aligned instead of vanishing, and a value containing both a comma and a quote round-trips.
npm run checkand the full integration suite pass.Closes #34