Changes

This article is part of the [[Advanced User's Guide]]. It describes how client operations are logged by the server.The server logs can e.g. be used to get an overview of all processes executed on your server, trace any errorsor compile performance statistics.

The server logs are written in plain text. In your [[Configuration#Database Directory|Database Directory]], you can find a folder named <code>.logs</code> in which all log files are stored with the according date. Note that, depending on your OS and configuration, files and folders beinning beginning with a <code>.</code> may be hidden. The log directory can be changed via the {{Option|LOGPATH}} option. If BaseX is used in a [[Web Application]], all trace output (generated via {{Code|fn:trace}}, {{Function|Profiling|prof:dump}} and similar functions) will be stored in the logs as well.

* Logging can be turned on/off via the [[Options#LOG{{Option|LOG]] }} option.* The maximum length of logging messages can be changed via [[Options#LOGMSGMAXLEN{{Option|LOGMSGMAXLEN]]}}.

By default, RESTXQ code is executed with the {{MarkCode|Introduced with 8.6admin}} Non-trivial web applications provide user. As a result, this user will be displayed in the ability logs for users to sign in and outall RESTXQ requests. User handling can be realized In a web application with session attributes (see e. g. a custom user management, however, the name of the [[DBA]] code)actual user who has sent a request is often more relevant.

By default, RESTXQ code When log data is run with admin permissions. However, as it is more interesting to know which user has called written during the processing of a RESTXQ function, the RESTXQ user string (which following is {{Code|admin}} by default, and which will show looked up in the log data) will be overwritten by the value of an {{Code|id}} session attribute. If the request path includes {{Code|/dba/}}, the {{Code|dba}} session attribute will be assigned.as follows:

If # The current request is checked for an {{Code|id}} attribute. The attribute can be assigned via RESTXQ and the following {{Function|Request|request:set-attribute}} function , and it is the recommended approach for stateless requests as all request attributes will be dropped after the finalization of a request.# If none is called more than oncefound, the {{Code|joeid}} will appear as user attribute is looked up in the second and subsequent log entries: <pre class="brush:xquery">import module namespace Session = 'http://basexcurrent user session.org/modules/session';declare %rest:path('/session-id') function local:f() The attribute can be assigned via {{ Function|Session|session:set}} ('id', 'joe'see e. g. the [[DBA]] code for sessions and user handling). If the request path contains a {{Code|dba}} segment, 'I am Joe'a {{Code|dba}};session attribute will be looked up instead.</pre># If none is found, the default path will be taken, and the user of the current database context will be included in the logs.

* Updated: Evaluate Include session attributesin log data.