Logging Management - Use Custom Logging Handlers #7
Conversation
antoviaque
force-pushed
the
logging-handler
branch
2 times, most recently
from
acacacf
to
798a6c2
Compare
| fields=[ | ||
| ('id', models.AutoField(serialize=False, auto_created=True, verbose_name='ID', primary_key=True)), | ||
| ('created', django_extensions.db.fields.CreationDateTimeField(default=django.db.models.fields.NOT_PROVIDED, verbose_name='created', auto_now_add=True)), | ||
| ('modified', django_extensions.db.fields.ModificationDateTimeField(auto_now=True, default=django.db.models.fields.NOT_PROVIDED, verbose_name='modified')), |
There was a problem hiding this comment.
@antoviaque All LogEntry models have a modified field. Do we ever expect log entries to be modified after they are created? I would expect log entries to be immutable.
There was a problem hiding this comment.
@mtyaka This comes from the TimeStampedModel mixin from Django extensions, it's present on all models. Log entries aren't expected to change, no, but the field doesn't seem harmful either - creating a new mixin without the modified field to replace https://github.com/django-extensions/django-extensions/blob/199e659fd8339d09e809d257f485eeda1b7f9e93/django_extensions/db/models.py#L19 might be more trouble that it's worth.
There was a problem hiding this comment.
@antoviaque Oh, I see... It's not worth it then, the field doesn't do any harm.
Use LoggerAdapters to attach standard logger functions to given objects, and a dedicated LoggingHandler to route the incoming log messages to the database & client display.
antoviaque
force-pushed
the
logging-handler
branch
from
9b289b1
to
783b910
Compare
Using the `default` field attribute was confusing automatically generated migrations, generating a new one when settings don't match.
|
@mtyaka I've also rebased to stay in sync with the other recent changes on master. This should be ready for another pass. |
|
@antoviaque Looking good 👍 |
Logging Management - Use Custom Logging Handlers
# This is the 1st commit message: Re-writing circle.yml to store code coverage in CircleCI's workspace and collect them afterwards. Test run parallelization is used with environment variables instead of using custom test runner. # This is the commit message #2: Update Makefile message. # This is the commit message #3: Remove cov.html from cov.combine. # This is the commit message #4: Stop running all tests in all containers # This is the commit message #5: Cleanup # This is the commit message #6: Experiment with different IDs for each coverage report # This is the commit message #7: Gathering raw coverage from all steps # This is the commit message #8: Always copy coverage and log message when not found # This is the commit message #9: Log copying raw coverage files for debugging
Use LoggerAdapters to attach standard logger functions to given objects, and a dedicated LoggingHandler to route the incoming log messages to the database & client display.