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 debug parse command #45

Closed
msm-code opened this issue Apr 13, 2020 · 3 comments
Closed

Add debug parse command #45

msm-code opened this issue Apr 13, 2020 · 3 comments
Labels
status:needs more design Non-trivial design issues invoved. Ask maintainers before working on

Comments

@msm-code
Copy link
Contributor

msm-code commented Apr 13, 2020

We need a way to introspect the running database, or debug some issues without either recompiling the db with debug prints or attaching with gdb.

Especially now that I'll be working on query parsing & optimisation, I have a few ideas in mind. Right now I'd like to have something easy - debug parse command:

debug parse index "hmm" with [gram3];

Will parse the command index "hmm" with [gram3] in this case, pretty print the parsed tree and return it to the user. Expected result is for example:

index
    "hmm"
    index_type_list
        gram3

(or whatever the real query tree looks like).

This can be returned as a structured JSON or as plain text - it's intended for debugging so we don't make any guarantees about the output.

@msm-code msm-code changed the title Add debug commands Add debug parse command Apr 13, 2020
@chivay
Copy link
Contributor

chivay commented Apr 13, 2020

I'm not sure if modifying language is the way to go.

Why isn't a stderr debug print good enough?

@msm-code
Copy link
Contributor Author

msm-code commented Apr 13, 2020

Two reasons:

  1. Adding an ad-hoc debug print every time and removing it before the commit sounds tedious. That's pretty common (for me) when writing a new commands.

  2. While parsing is pretty low level (I've chosen it, because it's the easiest debug command I could think of), I have more use cases for this. For example debug querygraph [query] which will return a query graph produced from the input. In the future maybe even debug queryplan [query].

  3. Of course these can all be solved with enough debug prints, but if we continue making new releases and changing the parsers, we may need to debug a compiled ursadb instance, and understanding the querygraph used may be a blessing.

What do you think? 🤔

@chivay chivay added the status:needs more design Non-trivial design issues invoved. Ask maintainers before working on label Apr 13, 2020
@msm-code
Copy link
Contributor Author

msm-code commented Nov 26, 2022

Since @chivay 's not a fan of this change, I don't have a lot of spare time to work on this, and it really is not overly important, we can probably scrap this issue. I don't forsee adding a lot of new commands in the coming months anyway (I expect working on querygraphs, but I can begrudgingly accept debug prints for this).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status:needs more design Non-trivial design issues invoved. Ask maintainers before working on
Projects
None yet
Development

No branches or pull requests

2 participants