2.3. Debugging RQL — CubicWeb 3.13.2

### Navigation

- index
- modules |
- next |
- previous |
- CubicWeb 3.13.2 »
- Appendixes »
- 2. Relation Query Language (RQL) »

# 2.3. Debugging RQL

## 2.3.1. Available levels

Server debugging flags. They may be combined using binary operators.

`cubicweb.server.` `DBG_NONE`
  no debug information

`cubicweb.server.` `DBG_RQL`
  rql execution information

`cubicweb.server.` `DBG_SQL`
  executed sql

`cubicweb.server.` `DBG_REPO`
  repository events

`cubicweb.server.` `DBG_MS`
  multi-sources

`cubicweb.server.` `DBG_MORE`
  more verbosity

`cubicweb.server.` `DBG_ALL`
  all level enabled

## 2.3.2. Enable verbose output

To debug your RQL statements, it can be useful to enable a verbose output:

    from cubicweb import server
    server.set_debug(server.DBG_RQL|server.DBG_SQL|server.DBG_ALL)

`cubicweb.server.` `set_debug`(debugmode)
  change the repository debugging mode

## 2.3.3. Detect largest RQL queries

See Profiling and performance chapter (see Profiling and performance).

## 2.3.4. API

class `cubicweb.server.` `debugged`(debugmode)

  Context manager and decorator to help debug the repository.

  It can be used either as a context manager:

      >>> with debugged(server.DBG_RQL | server.DBG_REPO):
      ...     # some code in which you want to debug repository activity,
      ...     # seing information about RQL being executed an repository events.

  or as a function decorator:

      >>> @debugged(server.DBG_RQL | server.DBG_REPO)
      ... def some_function():
      ...     # some code in which you want to debug repository activity,
      ...     # seing information about RQL being executed an repository events

  The debug mode will be reset to its original value when leaving the “with” block or the decorated function.

### Navigation

- index
- modules |
- next |
- previous |
- CubicWeb 3.13.2 »
- Appendixes »
- 2. Relation Query Language (RQL) »