#3939 Acceptable boolean syntax differs for data writes and data queries

[apriendeau]

So I made the assumption that T and F are acceptable boolean values but I am not sure where the stance is on supporting that including all the variations of the true/false but if that is the case and we do decide to go forward with this, there are tests to cover all the variations of true/false. So I guess, I am asking which direction we would like to go.

[otoolep]

Thanks @apriendeau -- have you signed the CLA?

Also, the commit messages are not very clear. Can you squash the two commits, and include a clearer commit message?

[otoolep]

Please give yourself credit here Thanks @apriendeau is what we like to write.

[apriendeau]

you want me to thank myself? lol

[otoolep]

If you don't, we will. :-)

[apriendeau]

okay, I appreciate it.

[otoolep]

I like the idea of symmetry, so I am OK with this. +1

@dgnorton

[apriendeau]

@otoolep edit squashed, reworded to be more clear and signed the CLA

[dgnorton]

I don't like having t and f as keywords in the query language. In the write path, single character bools save network traffic and parsing time, which will add up when processing billions of points. Most of those points are machine generated and never looked at by humans. Queries are low volume by comparison and often looked at by humans. Let's get a few more opinions. I may get out voted. :) @pauldix @benbjohnson @corylanou @beckettsean @DanielMorsing ?

[otoolep]

I don't have a strong opinion, you raise a fair point @dgnorton

[benbjohnson]

I'm not a fan of t and f as keywords either. I'd rather we limit keywords as much as possible.

[apriendeau]

I am not a fan of 't/f' as keywords but isn't it implied when you can use it in a write? So if we remove it, I would suggest that we only have true/false because having it on one side or the other, implies that it is a keyword. Currently we have:

Boolean syntax	Writes	Queries
t,f	✓	❌
T,F	✓	❌
true,false	✓	✓
True,False	✓	✓
TRUE,FALSE	✓	✓

I am in favor of removing t/f but I do think the best syntax to not support it for writes either and do a conversion under the hood for writes so that you are always getting the performance. Essentially, I think t/f should be treated as strings and not a special case.

[toddboom]

@apriendeau i think it might be good to also have some coverage of this in an integration test to demonstrate that it's correct all the way through the system. also, i think @corylanou's suggestion to do #4037 alongside this is a good idea.

[benbjohnson]

@apriendeau That's a good point. I think I'd personally rather see t/f removed from writes rather than added to the query language.

[apriendeau]

@toddboom Sure, I can would be more than happy to add #4037 that to PR while we are discussing the syntax 👍

[apriendeau]

@toddboom @corylanou Which way would you guys lean towards for acceptable write/read for booleans? If we are looking towards the other route, which is to remove support for t/f in the write query, I will probably close this PR and opened a new one.