| Summary: | Job errors should be stored on a separate location | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Tomás Cohen Arazi (tcohen) <tomascohen> |
| Component: | Architecture, internals, and plumbing | Assignee: | Bugs List <koha-bugs> |
| Status: | NEW --- | QA Contact: | Testopia <testopia> |
| Severity: | enhancement | ||
| Priority: | P5 - low | CC: | dcook, jonathan.druart, julian.maurice, tomascohen |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Change sponsored?: | --- | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
| Bug Depends on: | |||
| Bug Blocks: | 35092 | ||
|
Description
Tomás Cohen Arazi (tcohen)
2024-05-21 00:07:04 UTC
Right now it is the job's responsibility to manipulate the `data` column adding error messages. Which seems weird. (In reply to Tomás Cohen Arazi from comment #1) > Right now it is the job's responsibility to manipulate the `data` column > adding error messages. Which seems weird. Weird but more flexible. We could however add more helpers to Koha::BackgroundJob to not need to deal with data directly. But personally I don't think we need a separate DB column for that. We could have a test on store to make sure data is a correct JSON encoded string. What do you think about a background_jobs_logs table ? With columns such as: background_jobs_logs_id, background_jobs_id, timestamp, level, message. (In reply to Jonathan Druart from comment #2) > (In reply to Tomás Cohen Arazi from comment #1) > > Right now it is the job's responsibility to manipulate the `data` column > > adding error messages. Which seems weird. > > Weird but more flexible. We could however add more helpers to > Koha::BackgroundJob to not need to deal with data directly. But personally I > don't think we need a separate DB column for that. I've been thinking of the use cases we have, and I think a `feedback` column that doesn't mix the job data with errors or feedback of any kind is better than mixing the job parameters with feedback on the same data structure. (In reply to Julian Maurice from comment #3) > What do you think about a background_jobs_logs table ? > With columns such as: background_jobs_logs_id, background_jobs_id, > timestamp, level, message. I didn't think of 'level', but this is were I ultimately was headed to. |