Summary: | Why do we send jobs params to the broker | ||
---|---|---|---|
Product: | Koha | Reporter: | Jonathan Druart <jonathan.druart> |
Component: | Architecture, internals, and plumbing | Assignee: | Bugs List <koha-bugs> |
Status: | In Discussion --- | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | dcook, m.de.rooy, martin.renvoize, 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: | 32305, 22417, 32393 | ||
Bug Blocks: | 35092 | ||
Attachments: | Bug 32395: Do not send job's parameters to the broker |
Description
Jonathan Druart
2022-12-02 14:07:43 UTC
We would have avoided all the JSON encoding/decoding stuffs we had recently, and bug 32393. (In reply to Jonathan Druart from comment #0) > Why don't we simply pass the job_id to the broker, then retrieve the > parameters from the DB in the worker? In theory, a loosely coupled message consumer might not have database access to the app, so you'd want to encapsulate everything it needs in the message. However, the system designed for Koha is tightly coupled, so yeah... we could just pass the job_id in the message and have the worker fetch the details. It adds more database I/O, but it probably wouldn't be significant. In some cases, it could actually be more efficient. I don't know what the best practice is, and I imagine we should just do whatever makes sense for us. In the context of bug 32393 I see your point even more clearly. Since we're tracking jobs in the database and not doing a fire and forget pattern, it probably does make sense to just pass the job_id, because the message really is just "oh hey, I've got a job. Here's it's ID. Grab it and do stuff with it." Created attachment 144434 [details] [review] Bug 32395: Do not send job's parameters to the broker The logic is here, but I don't think this is enough. It must be more robust and clear. Do we allow other parameters than job_id? Should we simply pass the id as a string an completely remove JSON? I don't think so, we should keep flexibility and keep in mind we could have jobs that don't go through the DB. (In reply to Jonathan Druart from comment #5) > The logic is here, but I don't think this is enough. It must be more robust > and clear. Do we allow other parameters than job_id? Should we simply pass > the id as a string an completely remove JSON? > > I don't think so, we should keep flexibility and keep in mind we could have > jobs that don't go through the DB. Let's pass a JSON with the job_id. |