Open markcurtis1970 opened 1 month ago
@markcurtis1970 When I wrote that ingest code using bufio.Scanner
, in my soul I knew I'd have to answer to that 64K limit some day...
If you have a specific (cleansed) file you can share that breaks the ingester, it could be added as a test case.
I don't think this is an insurmountable problem. The Scanner
is basically only being used for line breaks.
Note, in general: that jsonl
ingester code is pretty awful (and the other JSON ingesters too). There's been very little attempt at any sort of optimization (or even doing it right). The whole thing should probably be thrown away and rewritten.
I'm very open to a PR, and contributors in general, not just for this part of the codebase, but for the entire project.
...in my soul I knew I'd have to answer to that 64K limit some day...
Haha yeah I know that feeling! (im gonna have to circle back to this)
Sure, thanks - I was going to try a PR but there wasnt a file object to get the stat
from and my "go-fu" is intermediate at best ;-) otherwise I would love to help!
I'll see if I can sanitise that file in the meantime!
Describe the bug When using the jsonl source larger files might exceed the standard bufio limit
To Reproduce Read in a large file
Expected behavior Ideally we should cope with larger lines
sq
versionPaste the output of
sq version --yaml
into the code block below:Source details
Source didnt load so had no further detail
Logs
Screenshots n/a
Additional context
When using a bufio.NewScanner the default is 64k
https://pkg.go.dev/bufio#Scanner.Buffer
I have used this example in code before with success
https://stackoverflow.com/questions/39859222/golang-how-to-overcome-scan-buffer-limit-from-bufio/66876416#66876416
However in the this part of the code the file isnt present so we cant really get the info from
file.Stat()
https://github.com/neilotoole/sq/blob/master/drivers/json/ingest_jsonl.go#L38