-
Notifications
You must be signed in to change notification settings - Fork 120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Attribute modifiers #17
Comments
Why not use them as functions? E.g.
|
@jorbs I was originally considering using function syntax as well, but I decided against it for a few reasons --
That being said, it seems like most people do prefer function syntax, so I'll probably end up going with that anyways! 😄 |
Hi, I should have asked you before working on this. I was just playing around the code of this and implemented something of this sort. Please see if its of any use or not: #23 |
Hey @khageshpatel, no worries! I'll get to reviewing and testing that right away! |
I ended up opting with the function notation for this to be consistent with SQL syntax. I also introduced an "interactive" mode in hopes of mitigating the need for escaping parentheses (which was my main concern with this notation, as mentioned above). See README.md#attribute-modifiers for the full documentation. |
A lot of suggestions have revolved around modifying attributes in some way (#3, #15).
Attribute modifiers will apply some change to the attributes in the
SELECT
andWHERE
clauses.I'm most fond of the following syntax right now. Of the ideas suggested, it's the easiest to parse (particularly for chained modifiers), while still being intuitive. I'm open to ideas if anyone has a suggestion.
As I mentioned in #15 (comment), one of the downsides of a syntax like this is that we're moving away from SQL (i'm not entirely sure that this is even a problem).
The text was updated successfully, but these errors were encountered: