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
Add ability to search by arbitrary metadata #568
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like it's headed the right way (:+1:) but you are missing the query language part for now.
6fd211d
to
2ada815
Compare
Right, that's only needed for the web part, correct? Unless you insist, I would be happy to leave that out from the current PR. I've updated the commit message to say it handles the cmdline piece. Thanks. |
No, it's also possible to use it with the CLI and the termui. I really don't want to have some features of the query language only supported in specific condition, so we should achieve parity. |
2ada815
to
1a9cd4b
Compare
works for me now, could you please take a look? Thanks. The commit message is unchanged, as the query language is working from the cmdline, but I didn't do anything for the web UI explicitly. |
@MichaelMure can I help you in some way to get this reviewed or should I just wait more? (I can wait, I'm just a bit confused if you expect something from me or not). Thanks. |
Sorry, things takes time sometimes :) Don't worry, your contribution is not lost. |
1a9cd4b
to
6d8e709
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, I think the last step is going to be completing the lexer/parser tests with those new cases.
query/lexer.go
Outdated
if len(split) == 2 { | ||
tokens = append(tokens, newTokenKV(split[0], removeQuote(split[1]))) | ||
} else { | ||
rest := strings.Join(split[2:], ":") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this should really accept more than two :
in a token.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have an alternative syntax in mind? I currently propose metadata:github-url:https://github.com/author/myproject/issues/42
, but that means there will be 3 colons, even if the third is not interesting. I.e. if you ban > 2 colons, then colons are not allowed in metadata, which means URLs are not allowed in metadata, which would be sad.
Once we settle down on the syntax, I can take a look at the tests. :-) Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hu, good point. Man, those formal grammar lessons that I barely listen to are quite far now ;)
After some idea shuffling, I'm thinking that the good solution might be to use quotes. It's already possible to do that: author:"René Descartes"
. So in your case it would be metadata:github-url:"https://github.com/author/myproject/issues/42"
.
Also, the command line parse behave in a similar way, no? Would git-bug ls --metadata github-url="https://github.com/author/myproject/issues/42"
be accepted? Not that it would be required as long as the shell is happy, but some uniformity would be nice.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like your proposal, and it may work for the webui, but the trouble is that the shell eats these quotes. So if I say meta:gh:"foo", I only get meta:gh:foo in go. You may require the user to type meta:gh:\"foo\", but that would be terrible usability.
Considering these, I would argue that either the current syntax is not that bad after all, or if you really would like some different syntax, then perhaps metadata:github-url=..., so it would be more obvious that the remaining characters are a value.
Unless we would go full json and allow something like metadata:{"github-url": "..."}, but again, typing that manually... ;-)
Which one would do you prefer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So if I say meta:gh:"foo", I only get meta:gh:foo in go.
Is that really the shell or cobra? What do you get with meta:gh:"foo bar"
?
--> I tested that, it's indeed go, but, go only unquote that and we get the args separated properly.
--> Actually, I had this problem before and to deal with it the ls
command put the quotes back: https://github.com/MichaelMure/git-bug/blob/master/commands/ls.go#L93-L98
So, some shenanigan happen in the process but from the CLI side and parser side, it looks and behave as we expect it to.
then perhaps metadata:github-url=...
That could be an alternative way. The grammar would be only 1-tuples (for the full text search) and 2-tuples for the filters/sorting. No 3-tuples.
In the later case, we would still need the quotes IMHO, to make the grammar a bit more regular. Having :
suddenly not being a separator because we already found two doesn't sounds like a great idea. What if we have 4 parameters next? It's unlikely but it would break the previously valid queries.
Considering this, this later syntax doesn't have much interest, no? What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right. :-) One more thing I forgot is that the cmdline can always use ls --metadata github-url=https://github.com/author/myproject/issues/42
, so using the query language is not a must. So in case we go with the metadata:github-url:"https://github.com/author/myproject/issues/42"
, that would be fine: it would be a good syntax (later) for the webui, and the cmdline can use metadata:github-url:\"https://github.com/author/myproject/issues/42\"
if it really wants to use the query language for metadata.
Is this OK? If so, then I could have a go at updating the code to do this.
Example: ~/git/git-bug/git-bug ls --metadata github-url=https://github.com/author/myproject/issues/42 or ~/git/git-bug/git-bug ls metadata:github-url:\"https://github.com/author/myproject/issues/42\" Fixes the cmdline part of <MichaelMure#567>.
6d8e709
to
cb61245
Compare
I've now implemented the foo:bar:"https://www.example.com/" syntax idea, also added tests. Please let me know if anything else is missing. |
@MichaelMure can I help with anything to get this reviewed? Thanks. |
Nothing to do on your side, it's just that real life and day job don't give me much spare time. |
query/lexer.go
Outdated
split := strings.Split(field, ":") | ||
// Split using ':' as separator, but separators inside '"' don't count. | ||
quoted := false | ||
split := strings.FieldsFunc(field, func(r rune) bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had this exact function to handle the quotes at some point, before writing this more complex/robust lexer. I don't remember exactly why, but IIRC this left a few edges cases open (maybe the unmatched quote?). I'll dig a bit to see if there is a better way to do that. Otherwise, this can be merged, because, well, it works.
I ended up doing some refactoring/code golf to use the same split function to split on spaces and on I think it's good to go now! Thanks for the help :) |
Thanks for reviewing this! :-) |
Example:
~/git/git-bug/git-bug ls --metadata github-url=https://github.com/author/myproject/issues/42
Fixes #567.