You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
logging should be a slightly better way to deal with increasing need for output and possibly different locations for the output
Considerations
Which errors needs to go to stderr , are they a fault with the application or are they handling something expected but unusual in the data and therefore need to notify the user
What level to use for what errors?
Does the data run log that is on the dashboard capture both stderr and stdout?
We often use call_command and check the output is expected. In call_command the stderr and stdout are local to that instance rather than sys.stderr/stdout
What is a useful string format for the logging (do we want it always in a CSV format for example)
or in each management command we could setup the handler
#...fromdjango.core.management.baseimportBaseCommand, CommandErrorfromloggingimportStreamHandlerlogger=logging.getLogger(__name__)
handler=StreamHandler()
logger.addHandler(handler)
# class Command(BaseCommand) [ this is the context ] :defhandle(self, *args, **options):
# By default 'logging' will log to sys.stderr which means that call_command does not capture any output with it's `stderr=<StringIO>` handler.setStream(self.stderr)
#...
The text was updated successfully, but these errors were encountered:
* Add funder name, publisher name and always output grant id
* Add test for correct output
* Fix missing output for funder ids
* Move function check_grant_data_tools_compatible into base class
* Rework the logging to use print until we tackle logging issues more
generally due to needing to add test cases with call_command.
see #231
* Add funder name, publisher name and always output grant id
* Add test for correct output
* Fix missing output for funder ids
* Move function check_grant_data_tools_compatible into base class
* Rework the logging to use print until we tackle logging issues more
generally due to needing to add test cases with call_command.
see #231
Switching to using
logging
logging should be a slightly better way to deal with increasing need for output and possibly different locations for the output
Considerations
call_command
and check the output is expected. In call_command the stderr and stdout are local to that instance rather than sys.stderr/stdoutdjango call_command
A wrapper for call_command?
or in each management command we could setup the handler
The text was updated successfully, but these errors were encountered: