What is a watch point ?

The gdb documentation has a very broad definition:

"You can use a watchpoint to stop execution whenever the value of an expression changes, without having to predict a particular place where this may happen."

The most common definition I found on the internet is a bit more restrictive:

"a watchpoint is a breakpoint that suspends execution whenever a specified field is accessed or modified."

Replace of course "field" by "attribute", "column value" according to context. The first page of results had this definition in the context of IBM SQLJ, Eclipse and… SAP debugging tools.

It is well known that pdb does not have watch points, even in the simple sense of tracking object attributes. I've always felt that it didn't really need them, because it's run from within the language, and one can set very flexible conditional break points that can do the job in most situations. Not to say that Eclipse Java debugger doesn't have conditional breakpoints, mind you, but it's a different feeling.

Simplest example of conditional break points:

if self.x == 1234: pdb.set_trace()

Why pdb conditional break points aren't enough to debug openobject application code

First, I should state the obvious : it's a matter of saving time.

Downstream application code is about putting things together, and hence involves lots of different objects. It can be also hard to track, because that's where you get to read those methods with several hundred of lines, five levels of if/then/else blocks, redundant loops, counter-intuitive method namings…

So, let's say the value of some model's column is set and you don't know where in the code that may have happened. It could a side effect of about anything. In openobject, as well as most SQL based applications, lots is done through foreign ids. In general, if the object one's interested in is the identical between different runs of the software, one may very well find its id with pdb or a log line, and restart the server with a simple conditional breakpoint in the write method of the appropriate osv subclass.

But there are many cases where the object cannot be reused in subsequent runs, therefore the interesting id changes all the time. This happens e.g if you have to set the workflow state of some intermediate model in the reproducing process and can't undo that. Imagine for instance a bug in the accounting lines produced by an invoice confirmation. This is frustrating, because you know very well the interesting object's id from the code : it's typically stored in a variable that sits right in front of your eyes.

Another slow down for pdb conditional breakpoints in the openobject context is the models inheritance system, making it not so obvious to find the correct class where to put them : the write method can be overridden from about anywhere, and you'll lose time finding it, too.

How could a watch point system for openerp look like

I'm thinking of something like this:

account_line.watchpoint(meth='write', ids=interesting_ids)

This would intercept all calls to the write method for the account_line model and set a conditional breakpoint related to the interesting ids. Then you can climb up the call stack.

I don't imagine this in the main openobject-server code, but rather keep it separated by using a dedicated launcher for the server. It looks like a typical exercise in metaclass programming.

I did some experiments already and am very close to a working proof-of-concept. Probably more on that later, have to try it in real life.

Why not IDE ?

Granted, a debugger running from outside of the process being debugged would also be useful for that kind of introspection, since they don't require restarting the server. That's typically the IDE way of doing. But…

• I think pdb's ubiquity is valuable, and adding the kind of watchpoints I propose here is lightweight and can work no matter the context, e.g, on a headless development server
• there's lots of freedom in the above proposed approach, and hence room for potential further powerful developments
• I don't like IDEs overall. Yes, that's a matter of personal taste and I love python for being manageable with no IDE, but it also comes to its own laziness : I haven't investigated python IDEs much :-)