Should saved job messages be their own model? about silverstripe-queuedjobs HOT 3 OPEN

I'm not against the idea, but it does need to be looked at against the context of why it was there in the first place. Originally it was just meant to capture any details of what the management service was doing around the job; however it then became a bit more 'loggy' than was probably intended. And I'd rather avoid having log messages filling up the database, when they should probably be logged to an external mechanism somehow.

From an API point of view, I'd rather the job class didn't know at all about its descriptor, so the mapping of the message list back to objects would be back at the job service level.

from silverstripe-queuedjobs.

In a SS4 context, could you handle this using a custom monolog handler?

from silverstripe-queuedjobs.

Need to validate if this is still a problem for ss4.

from silverstripe-queuedjobs.