- achap 🇦🇺
I see what you mean looking at the code now. I guess the same would be true for the
pushImport
feed handler as it uses queue api and would have the same lease times. Does that mean I should remove the changes above forcronImport
andpushImport
or should it be left as is?I'm only using the
import
(via drush) andstartBatchImport
methods in my project so haven't tested the other methods. - 🇳🇱Netherlands megachriz
@achap
cronImport()
andpushImport()
at least look broken to me. So because of that I think you could leave them out for your patch.I have in fact played with the idea of putting feed imports in a specific order on cron run. And I drafted a module for that (which I haven't published yet because its features would overlap with this project). Before the start of the first import it calculates which feeds need to be imported and in what order. That data is written to a state variable. An event subscriber listening to the
FeedsEvents::IMPORT_FINISHED
event then checks if it should start an other feed import by checking the state variable.One issue I ran into though is that all feeds part of the sequence need to get locked. Else the order cannot be guaranteed. Because an other process could start an import for the second feed while the first one is still running. But if a feed is already locked, the event subscriber cannot start a cron import for that.
An other limitation of the module as I wrote it is that only one sequence of imports can be started at the same time. And if one of the feeds in the sequence has already an import running, starting the import sequence fails.
But maybe all this should be addressed in a separate issue so this issue can concentrate on the batch import in the UI specifically. ;)
- First commit to issue fork.