On Sunday, January 31, 2016 at 7:12:41 AM UTC+1, Dave S wrote: > > > > On Saturday, January 30, 2016 at 8:50:32 PM UTC-8, Niphlod wrote: >> >> scheduler_run is the only way to keep track of executions. >> > > And there is no session to carry a value over in, is there? >
sorry, what ? > > >> BTW, in my experience, changing models doesn't need a restart. >> >> > That's what I was expecting, but when I added the return to the wrapper > function, it didn't seem to have an effect until I did a restart. > > And for the module code, if I had invoked it from a Web2Py shell, would > that have recompiled it, or would the restart still be needed? > the web2py shell (lanched with -M -S appname) has the same environment controllers are executed in. neither models or modules are evaluated once you're in it. it's like suspended animation :-P . The scheduler spawns a fresh process for each executed task, and basically resorts to openinig a shell and executing the function you queued every time. This has nothing to do with compiled applications (ala web2py, when you find a "compiled" dir): those are another matter entirely because web2py will look for compiled files before non-compiled ones. For all matters and purposes, a compiled app is crystalized hence executing it in the shell or in the scheduler while altering models or modules has no effects so far. > > /dps > > >> On Saturday, January 30, 2016 at 10:31:40 PM UTC+1, Dave S wrote: >>> >>> I've finally done a scheduled task (and not for the project I thought I >>> was going to). In the current context, the plan is to use the scheduler to >>> check for POSTs that have come in since the last run, and using the list as >>> the body of a email notification to the steward/responsible-party who is >>> supposed to monitor the list. And for that, I need a "since" time. >>> >>> For various reasons, in this project I have an artifact in the file >>> system that's easy to fstat, but I'd like to know a more general solution >>> for the next time (or maybe even this time, if I'm impressed enough). >>> Would that be to take the last row in scheduler_run that matched the >>> function and had status COMPLETED? If you don't have a return value, is >>> there something else than scheduler_run entries that would be considered a >>> good practice? >>> >>> Sidebar: I almost outsmarted myself on my scheduler task. I put the >>> real work into a module, and then did just a wrapper in the model code. >>> And I didn't think about return values, but once I got to where I wasn't >>> getting a traceback but needed more debugging information, not having an >>> entry left in scheduler_run was a handicap. So I added print statements to >>> the module. Nada. I added a return statement to the module. Nada. Went >>> out to the car to drive home, and realized ... the function in the model >>> needed to return the return value. Went back in added that, and voila! >>> >>> Sidebar 2: For future readers, one further little detail was needed to >>> get to voila ... restarting web2py for changes in either the model or >>> module (I was using -K -X), because of when the "check for changes" code is >>> applied by the scheduler, which is at startup. >>> >>> So what do the fine folk here recommend for tracking the last time run? >>> >>> /dps >>> >>> -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
