-
-
Notifications
You must be signed in to change notification settings - Fork 536
[14.0] Add graph of dependencies #403
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
d46b548 to
3ca0f6f
Compare
f0b56b9 to
56be8a8
Compare
test_queue_job will create channels root.sub and root.sub.sub, so the tests doing the same thing will fail with a unique constraint error.
When displayed in a tab, the widget show the nodes offset, the d3 network is probably confused by the size or visibility of its canvas. Install a listener on tabs to trigger a fit() on the network.
A graph of jobs always share the same graph_uuid, which can be used to group jobs, but is also a faster way to find all the jobs of the graph. Then we can use the dependencies field to build the whole graph from the pre-selection of jobs.
Jobs waiting that their dependencies are executed cannot be requeued. They have to keep waiting their turn.
As jobs are created in the setup, but not always delayed, the __del__ warning that the job was not delayed is triggered. Create only the jobs necessary for each test.
* mock_jobs context manager with assert methods to check enqueued jobs * jobs are not stored in database, yet they can be inspected and performed during the test * the context manager works with graphs enqueued by delayable and with with_delay() * direct execution of jobs works with graphs by executing them synchronously following their topological sort
The previous implementation was incomplete, as it was setting the graph_uuid when `Job.add_depends()` was called. It had the advantage of being correct when (for e.g. a test) manually created a Job and called `add_depends()`, but it could not work when in some situations involving a group where one of the job has no job depending on it. Also, remove ``Job.add_reverse_depends()`` which is not used.
When showing large graphs, like 300 jobs (not really a real life case maybe), the graph takes a dozen of seconds to render. Disabling the stabilization helps a lot.
* Renaming the TestXxx models in test_queue_job is because of pytest that complains, confusing them for test classes * logger.warn is deprecated in favor of logger.warning * Add invalidation of cache in SQL update that enqueue dependent jobs * Flush in a test, the same is done currently in the controller * Weird one: we can no longer compare the bound methods of the models, compare their __func__ which is equal.
The assert fails to show the method's details if we store the __func__ in JobCall. Anyway, it was hackish to change the content of "method".
The fact that mocks are used is an implementation detail, and is actually hidden to the end user of the test API.
on_done() is maybe a better choice, it is less ambiguous than then() (clearer on the fact it happens on done()) and done() (less confusion with set_done()). I'll do the renaming soon, unless you have other suggestions. Ref: OCA#154 (comment)
simahawk
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Skimmed quickly through it, can't find anything bad... but I trust you did your homework 😜
COOOOL THANKS!
|
I totally trust the author credentials :) |
|
/ocabot merge major |
|
This PR looks fantastic, let's merge it! |
|
Congratulations, your PR was merged at b8311a4. Thanks a lot for contributing to OCA. ❤️ |
Migration of #154, details on the link.
You can test enqueuing a graph a jobs with test jobs by going on the runboat instance and doing a request on
/queue_job/create_test_job?size=30that will generate a random graph of 30 jobs. Jobs are not executed, but you can look at the dependency graphs ;)