Convenient handling of DBMS notifications #1059
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces support for a more convenient way of consuming notifications received from the DBMS server.
This feature is still in PREVIEW.
It might be changed without following the deprecation policy.
Logging
A new sub-logger
neo4j.notifications
is introduced.Every notification received will be logged through this logger.
The log-level is determined by the notification's severity.
If logging is not configured explicitly, warnings are logged to stderr.
This means that, by default, warnings like deprecations received from the DBMS will appear on stderr.
Warnings
A new driver-level configuration
warn_notification_severity
is introduced.It can be used to configure from which notification severity level upward the driver should emit a warning (i.e., call
warnings.warn
).By default (
None
), it will be set toOFF
(never emitting warnings on notifications), unless Python runs in development mode or the environment variablePYTHONNEO4JDEBUG
is set, in which case the driver will emit awarning on every notification.
Usage
This functionality if mainly meant for developing and debugging.
Therefore, no emphasis is put on efficiency.
However, it's impact is capt to a minimum when disabled.
It's assumed that in productions environments this feature is either disabled explicitly
or default behavior (see above) is used by not running Python in development mode.
Example
On an empty database, this leads to the following output: