This is a bit of a wild idea but I wonder if databow could show diagnostics to the user before they execute their query. Like in this case, I have to run my query to see my mistake but, technically, databow could ahve already known about the mistake beforehand:
$ databow --driver sqlite
> create table foo (x y z);
┌┐
└┘
> select foo.a from foo;
Failed to execute statement: InvalidArguments: [SQLite] Failed to prepare query: no such column: foo.a
query: select foo.a from foo (sqlstate: [0, 0, 0, 0, 0], vendor_code: -2147483648)
There are at least two ways a tool like databow could learn about what's valid and what's not: (1) from past commands and (2) from issuing GetObjects calls. In the above example, as I typed foo.a or just a, the name could have been colored red or something and we could even use other parts of the TUI screen to show the error. There may be good reasons not to do this such as false positives and false negatives (maintaining caches is hard). Just thought I'd write this idea down.
This is a bit of a wild idea but I wonder if databow could show diagnostics to the user before they execute their query. Like in this case, I have to run my query to see my mistake but, technically, databow could ahve already known about the mistake beforehand:
There are at least two ways a tool like databow could learn about what's valid and what's not: (1) from past commands and (2) from issuing GetObjects calls. In the above example, as I typed
foo.aor justa, the name could have been colored red or something and we could even use other parts of the TUI screen to show the error. There may be good reasons not to do this such as false positives and false negatives (maintaining caches is hard). Just thought I'd write this idea down.