Fork me on GitHub

@mihaelkonjevic I’ve published the missing deps, should work, but haven’t nuked my .m2 to really check


@sooheon I’ve managed to start it, but it seems that I need a DB to run the project. I’ll try to replicate the issue you reported in the manually-call-dataloader-example repo


Ah, sorry. Keep forgetting the obvious stuff. I’ll try my hand at clean repro tomorrow as well.


@sooheon I’ve updated the example repo, it works correctly for me . Now, to explain why it was behaving weirdly and why my controller looks different than yours. There was an issue with the pipeline controllers API which meant that you weren’t able to use synchrnous start and stop lifecycle functions. When Keechma starts the route change dance (starting and stopping controllers), first it calls (sync) stop functions on all controllers that need to be stopped, then it calls (sync) start functions on all controllers that need to be started, and then it starts the handler function on all started controllers. Implementation can be found here - , but the important thing is that Keechma guarantees this behavior for all controllers. Previously pipeline controllers were implemented just with the handler function which meant that their :start pipelines were always called asynchronously. Keechma doesn’t guarantee (by design) order in which the controllers will be started which means that something like this happened (order can be different as it’s aribtrary): 1. Dataloader controller started which started the dataloader (in this moment both [:kv :cascader] and [:kv :date-range] are nil) 2. Cascader controller’s :start pipeline is called which sets the [:kv :cascader] and restarts the dataloader 3. Date range controller’s :start pipeline is called which sets the [:kv :date-range] and restarts the dataloader This resulted with 3 calls to dataloader before we make the real request. In the last release of Keechma Toolbox, I’ve added ability to define synchronous start and stop functions for controllers (which have the same API as the normal controllers), and this is what I’m using in the example repo. You can see the commit here: . This also renames :start and :stop pipelines to :on-start and :on-stop while supporting the old API. Now you have an ability to synchronusly set [:kv :cascader] and [:kv :date-range] before the dataloader is started (since it’s started inside the handler function which is guaranteed to run after all start functions are done). The timeline now looks like this: 1. Cascader controller’s (sync) start function is called - this sets [:kv :cascader] 2. Date range controller’s (sync) start function is called - this sets ’[:kv :date-range]` 3. Dataloader is started - [:kv :cascader] and [:kv :date-range] already have their values set - which means that dataloader is started only once. I hope this clears it, and please do ask if you have any more questions


Also, dataloader calls params functions twice for each datasource that is being loaded - once to check if the datasource is stale and second time when it’s actually getting the params to load the datasource