Changeset - 3b1c53643b09
[Not reviewed]
stable
0 1 0
Mads Kiilerich - 6 years ago 2020-04-22 20:47:02
mads@kiilerich.com
Grafted from: fddfd8c4b84e
doc: fix wording of debug hint in contributing.rst
1 file changed with 2 insertions and 2 deletions:
0 comments (0 inline, 0 general)
docs/contributing.rst
Show inline comments
 
@@ -248,50 +248,50 @@ Objects can be added to the session usin
 
rarely needed:
 

	
 
* When creating a database object by calling the constructor directly,
 
  it must explicitly be added to the session.
 

	
 
* When creating an object using a factory function (like
 
  ``create_repo``), the returned object has already (by convention)
 
  been added to the session, and should not be added again.
 

	
 
* When getting an object from the session (via ``Session().query`` or
 
  any of the utility functions that look up objects in the database),
 
  it's already part of the session, and should not be added again.
 
  SQLAlchemy monitors attribute modifications automatically for all
 
  objects it knows about and syncs them to the database.
 

	
 
SQLAlchemy also flushes changes to the database automatically; manually
 
calling ``Session().flush`` is usually only necessary when the Python
 
code needs the database to assign an "auto-increment" primary key ID to
 
a freshly created model object (before flushing, the ID attribute will
 
be ``None``).
 

	
 
Debugging
 
^^^^^^^^^
 

	
 
A good way to trace what Kallithea is doing is to keep an eye on the output of
 
stdout/stderr from the server process. Perhaps change ``my.ini`` to log at
 
A good way to trace what Kallithea is doing is to keep an eye on the output on
 
stdout/stderr of the server process. Perhaps change ``my.ini`` to log at
 
``DEBUG`` or ``INFO`` level, especially ``[logger_kallithea]``, but perhaps
 
also other loggers. It is often easier to add additional ``log`` or ``print``
 
statements than to use a Python debugger.
 

	
 
Sometimes it is simpler to disable ``errorpage.enabled`` and perhaps also
 
``trace_errors.enable`` to expose raw errors instead of adding extra
 
processing. Enabling ``debug`` can be helpful for showing and exploring
 
tracebacks in the browser, but is also insecure and will add extra processing.
 

	
 
TurboGears2 DebugBar
 
^^^^^^^^^^^^^^^^^^^^
 

	
 
It is possible to enable the TurboGears2-provided DebugBar_, a toolbar overlayed
 
over the Kallithea web interface, allowing you to see:
 

	
 
* timing information of the current request, including profiling information
 
* request data, including GET data, POST data, cookies, headers and environment
 
  variables
 
* a list of executed database queries, including timing and result values
 

	
 
DebugBar is only activated when ``debug = true`` is set in the configuration
 
file. This is important, because the DebugBar toolbar will be visible for all
 
users, and allow them to see information they should not be allowed to see. Like
 
is anyway the case for ``debug = true``, do not use this in production!
0 comments (0 inline, 0 general)