Debugging

Here we would like to describe possible techniques that could help you to find and understand issues in your code.

Show stack trace

We provide ability to show line of code where the issue happens in case if code is written in onetick.py.

In code your set or otp.config['show_stack_info'] or the OTP_SHOW_STACK_INFO env variable to enable this option (more about it is here)

In tests your could use the --show-stack-trace option.

Dumping ticks

The .dump() method allows to print out incoming ticks, that might help to find ticks that leads to incorrect behaviour and reproduce it then in tests.

onetick view

onetick view is a terminal UI for browsing OneTick databases and their content.

This tool is built on the top of the onetick.py and distributed as a separate python package.

After installation a developer just needs to go to a folder with OneTick databases and executes the onetick view command in terminal – it automatically discovers databases and show them.

Usually it’s convenient to use this tool along with the --keep-generated flag in tests, because this flag provides all databases are used in tests with their content.

Save OTQ

Any otp.Source object has the .to_otq() method that allows to save a query on the disk with goal to check the OTQ graph. Note that this method has symbols and start/end query interval parameters that’s better to pass there the same as for otp.run because these parameters could change graph calculation.

It’s often useful when you think the onetick.py constructs the wrong calculation or you want to check some details.

Graph rendering

Alternatively we could propose to use the .render() method on the otp.Source that draws a query as the graphviz DAG. It could help with quick investigations because save OTQ requires a running tick server and connected to it OneTick client with necessary context.