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.

Non-trivial web applications provide the ability for users to sign in and out. User handling can be realized with session attributes (see e. g. the [[DBA]] code). By default, RESTXQ code is run executed with admin permissions. However, as it is more interesting to know which user has called a function, the RESTXQ user string (which is {{Code|admin}} by defaultuser. As a result, and which this user will show up be displayed in the log data) will be overwritten by logs for all RESTXQ requests. In a web application with a custom user management, however, the value name of an {{Code|id}} session attribute. If the actual user who has sent a request path includes {{Code|/dba/}}, the {{Code|dba}} session attribute will be assignedis often more relevant.

If When log data is written during the processing of a RESTXQ function, the following function is called more than once, {{Code|joe}} will appear looked up as user in the second and subsequent log entriesfollows:

<pre class="brush# The current request is checked for an {{Code|id}} attribute. The attribute can be assigned via RESTXQ and the {{Function|Request|request:xquery">import module namespace Session = 'http://basexset-attribute}} function, and it is the recommended approach for stateless requests as all request attributes will be dropped after the finalization of a request.org/modules/session';declare %rest:path('/# If none is found, the {{Code|id}} attribute is looked up in the current user 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.

01:31:51.888 127.0.0.1:4803 admin REQUEST [GET] http://localhost:89848080/rest/factbook