Skip to content
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

Merged
merged 2 commits into from Feb 27, 2021

Conversation

vmiklos
Copy link
Contributor

@vmiklos vmiklos commented Feb 14, 2021

Example:

~/git/git-bug/git-bug ls --metadata github-url=https://github.com/author/myproject/issues/42

Fixes #567.

Copy link
Owner

@MichaelMure MichaelMure left a 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.

cache/filter.go Outdated Show resolved Hide resolved
cache/filter.go Outdated Show resolved Hide resolved
commands/ls.go Show resolved Hide resolved
@vmiklos
Copy link
Contributor Author

vmiklos commented Feb 14, 2021

Looks like it's headed the right way (+1) but you are missing the query language part for now.

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.

@vmiklos vmiklos marked this pull request as ready for review February 14, 2021 21:04
@MichaelMure
Copy link
Owner

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.

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.

@vmiklos
Copy link
Contributor Author

vmiklos commented Feb 15, 2021

git-bug ls metadata:github-url:https://github.com/author/myproject/issues/42

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.

@vmiklos
Copy link
Contributor Author

vmiklos commented Feb 19, 2021

@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.

query/lexer.go Outdated Show resolved Hide resolved
@MichaelMure
Copy link
Owner

Sorry, things takes time sometimes :)

Don't worry, your contribution is not lost.

Copy link
Owner

@MichaelMure MichaelMure left a 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:], ":")
Copy link
Owner

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.

Copy link
Contributor Author

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.

Copy link
Owner

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?

Copy link
Contributor Author

@vmiklos vmiklos Feb 20, 2021

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?

Copy link
Owner

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?

Copy link
Contributor Author

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>.
@vmiklos
Copy link
Contributor Author

vmiklos commented Feb 21, 2021

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.

@vmiklos
Copy link
Contributor Author

vmiklos commented Feb 26, 2021

@MichaelMure can I help with anything to get this reviewed? Thanks.

@MichaelMure
Copy link
Owner

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 {
Copy link
Owner

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.

@MichaelMure
Copy link
Owner

I ended up doing some refactoring/code golf to use the same split function to split on spaces and on :. I believe this cover more edge cases, and it's also simpler.

I think it's good to go now! Thanks for the help :)

@MichaelMure MichaelMure merged commit 22cc4cc into MichaelMure:master Feb 27, 2021
@vmiklos vmiklos deleted the search-metadata branch February 27, 2021 22:31
@vmiklos
Copy link
Contributor Author

vmiklos commented Feb 27, 2021

Thanks for reviewing this! :-)

@GlancingMind GlancingMind mentioned this pull request Apr 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Search by arbitrary metadata
2 participants