Handling column names directly?

Typically, a csv file will have a header row (e.g. carat,cut,color,clarity,depth,table,price,x,y,z for the diamonds data set from ggplot2).

Is there a chance of adding an option to perform RBQL queries directly with the columns (e.g. carat) instead of having to reference them by their index (e.g. a1)?

[mechatroner]

So, I wrote the code to support a.good_alphanumeric_column_name and a["arbitrary column name!"] notation, it’s available in the master branch. Took me almost 150 commits [sigh] Soon I will start deploying it to the apps. And I would really appreciated any feedback, guys! Please, let me know what you think.

PS I rewrote JS implementation: replaced all callbacks with async/await so it should be much easier to read now.

[mechatroner]

Yep, I think that a.name, a.age, b.name, etc notations are the way to go. But there is no need to do replaceAll, because it is unreliable even with “a.” and “b.” prefixes. Original user query should be altered as little as possible. One case where it will definetely fail are string literals: should we replace a.name inside string literals? In case of SQL keywords (“SELECT”, “WHERE”, etc) the answer is no, and RBQL isolates string literals before it starts searching for the keywords. But in case of a.name the answer is not so obvious. Here is an absolutely artificial and contrived example, but it will fail with replaceAll:

SELECT `a.name = ${a.name}`

The output would be a1 = Andy instead of a.name = Andy. I agree that such situation would probably never happen in practice, but my general position still holds: original query should be altered as little as possible. This is also important for exceptions/errors that contain failed query expression, if the query was significantly altered it wouldn’t be recognizable by the user, and it would be harder to correct that error.

So to implement this “a.name” etc notations I suggest to initialize special “a” and “b” objects (if either “a.” or “b.” were detected somewhere in the query). This should be relatively easy to do - almost the same code that currently initializes a1, a2, b1 etc variables. “a” and “b” can also support square bracket access like a[“person name”]. Those who think that this is super ugly and non-SQLish can pretend that this feature doesn’t exist and only columns without whitespaces/special characters are supported. I don’t have 100% guarantee that this approach would work, but I currently don’t see why it wouldn’t, and the only way to be sure is to try and implement this.