scheduler: feature request

[Niphlod]

Please see this thread for references
https://groups.google.com/d/msg/web2py/l7eDM6_oVPg/z4AdgbEDYZYJ

@all: do you see any problems in supporting that behaviour in addition to the current one ?

Can the usual suspects (@anthony :P) figure out a nice name for the soon-to-be-added column ?

Thanks for the attention

[Anthony]

This is a tough one. Maybe something like:

Field('period_from', requires=IS_IN_SET(['Scheduled start', 'Actual start']),
      comment='Actual start may be later than scheduled start due to worker availability.')

I would lean toward making "Scheduled start" the default, though perhaps that creates a backward compatibility issue.

Anthony

[Niphlod]

uhm... definitely it should retain the "actual start" behaviour because lots of cases depend on it. 

I'm not positive about having to do

queue_task(......., period_from='Actual Start')

as "column names" are "translated" to API keywords. An argument that takes a set of "english strings" is not that clean....

That's why I suggested a boolean field, so you can do

queue_task(......., cron_like_behaviour=True)

but I totally get the "tough" process in figuring out the name ;-D

[Anthony]

Good point. I was thinking more of a form interface, where there would be a drop-down, but I agree it's not so nice via the API. It's difficult to come up with a sufficiently descriptive boolean name that isn't ridiculously long. We could use something like cron_like or cron_style, but its meaning won't be obvious without explanation. A bit long, but maybe something like period_from_actual_start or period_excludes_start_lag.

Anthony

On Friday, January 10, 2014 10:12:48 AM UTC-5, Niphlod wrote:

uhm... definitely it should retain the "actual start" behaviour because lots of cases depend on it. 

I'm not positive about having to do

queue_task(......., period_from='Actual Start')

as "column names" are "translated" to API keywords. An argument that takes a set of "english strings" is not that clean....

That's why I suggested a boolean field, so you can do

queue_task(......., cron_like_behaviour=True)

but I totally get the "tough" process in figuring out the name ;-D

On Friday, January 10, 2014 4:05:40 PM UTC+1, Anthony wrote:

[Alan Etkin]

 

Can the usual suspects (@anthony :P) figure out a nice name for the soon-to-be-added column ?

cronlike

My 1e-10 bitcoins

EDIT: or maybe the more niphlodian clike or cronl

[villas]

Suggestions...
IMO names that jog your memory in the right direction are best.

    revertstarttime
    -or-
    fixedtimetostart
    -or-
    staticstarttime

[Anthony]

fixed_start_times

[Brian Meredyk]

How about "consistent_start_time"?  

To me, fixed & static say that once I've set something for a 09:00 start it always stays at 09:00 no matter what (admittedly what I am after for a daily task). However what about a task set to run hourly instead of just daily? 09:00, 10:00, 11:00, 12:00, 13:00... aren't fixed or static but they are consistent start times. The start times remain consistent with the original starting time plus the interval * # times run.

Brian

[Niphlod]

even_start_time ?!

[Anthony]

Even with the current behavior, the start times are "consistent" -- they consistently start "period" seconds after the last actual start. As for "even", I think it's more likely to evoke the "opposite of odd" meaning, and even if interpreted as "equal in value", it's not quite clear what that would mean.

As for "fixed", note it is "fixed_start_times" (i.e., plural "times"). The idea is that once you set the start_time and the period, all subsequent start times are fixed.

Perhaps another approach is something like "prevent_start_drift" or "prevent_drift" (which would default to False).

The bottom line is that there is no way anyone will understand the meaning of this parameter (no matter what we call it) unless they read the documentation.

Anthony

[Brian Meredyk]

I like the prevent_start_drift option. Your probably right, regardless users will need to read the docs anyway in order to understand what it actually does and why they might care.

[Tim Richardson]

start_time in ['fixed_start','fixed_period']

[Anthony]

On Monday, January 13, 2014 12:47:45 AM UTC-5, Tim Richardson wrote:

start_time in ['fixed_start','fixed_period']

What does this mean? 

[Tim Richardson]

I meant that rather than trying to get the meaning clear in a boolean parameter, why not set a mode; this means that the meaning of the user's choice is conveyed more easily, since there is information in both the name of the parameter and its value. So you would specify start_time = fixed_start or start_time = fixed_period.
I find this approach more readable, plus it's more future proof since additional modes can be added more easily.

--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---
You received this message because you are subscribed to a topic in the Google Groups "web2py-developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/web2py-developers/68nGdKAmGmg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to web2py-develop...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Tim Richardson, Director GrowthPath, Data-driven profit growth Mobile: +61 423 091 732 Office: +61 3 8678 1850 I tweet useful business & IT tips at growthpath_au GrowthPath Pty Ltd ABN 76 133 733 963

[Anthony]

Got it. Note, we did discuss this approach, starting here: https://groups.google.com/d/msg/web2py-developers/68nGdKAmGmg/3tX8bri4K1sJ. Also, start_time is an existing argument, which holds a datetime value.

Anthony

[Niphlod]

let's go with prevent_drift ?

[Anthony]

On Monday, January 13, 2014 3:24:48 PM UTC-5, Niphlod wrote:

let's go with prevent_drift ?

+1 

[Tim Richardson]

Then pretend my post was a +1 on your idea  https://groups.google.com/d/msg/web2py-developers/68nGdKAmGmg/3tX8bri4K1sJ except I think "guaranteed period" better describes the existing functionality. I would have to think twice/read docs to understand the subtle difference between scheduled start and actual start. Also, "guaranteed period" is a feature; "prevent_drift" is a bug fix.
Can't existing behaviour be achieved by defaulting to guaranteed period or whatever to call it?


The functionality is good.

[paolo....@gmail.com]

For me is ok

--

-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---

You received this message because you are subscribed to the Google Groups "web2py-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py-develop...@googlegroups.com.

[Massimo DiPierro]

If this is for native english speakers, it is ok with me.

Massimo

[Anthony]

On Monday, January 13, 2014 3:39:13 PM UTC-5, Tim Richardson wrote:

Then pretend my post was a +1 on your idea  https://groups.google.com/d/msg/web2py-developers/68nGdKAmGmg/3tX8bri4K1sJ except I think "guaranteed period" better describes the existing functionality. I would have to think twice/read docs to understand the subtle difference between scheduled start and actual start. Also, "guaranteed period" is a feature; "prevent_drift" is a bug fix.
Can't existing behaviour be achieved by defaulting to guaranteed period or whatever to call it?

It's tricky because "guaranteed period" is true of both cases -- the period is always fixed (guaranteed, etc.). What is at issue is at what point you start measuring the period -- from the scheduled start time or from the actual start time. The timing is as follows:

S1-----A1-------------------S2

    x            y

where S1 is scheduled start 1, A1 is actual start 1, x is the time spent waiting for a worker, and y is the time from AS1 until the next scheduled start. Currently, period = y, and the proposal is to also allow period = x + y. So, the period is always fixed, it's just a matter of whether the period is defined as including the worker wait time or not (i.e., either x+y is fixed, or just y is fixed).

I agree that prevent_drift sounds a bit like a bug fix, but at least it's short and descriptively accurate. Previously I suggested period_excludes_start_lag (could also be period_includes_start_lag), but those are a bit long. I suppose it could be shortened to exclude_start_lag or exclude_lag_time or just exclude_lag.

Anthony

[Tim Richardson]

fair enough. Certainly this discussion will inform anyone looking for documentation before it goes in the book (I put my hand up for that).

[Niphlod]

+1. To me is more obvious expecting the actual behaviour than the newly requested when queueing task with "period" and "repeat" but I guess I'm remaining the only one  

It just sounds like a bugfix if you didn't get how scheduler was meant to be :-P

Will make a PR this evening.

On Monday, January 13, 2014 11:19:48 PM UTC+1, Anthony wrote:

On Monday, January 13, 2014 3:39:13 PM UTC-5, Tim Richardson wrote:

Then pretend my post was a +1 on your idea  https://groups.google.com/d/msg/web2py-developers/68nGdKAmGmg/3tX8bri4K1sJ except I think "guaranteed period" better describes the existing functionality. I would have to think twice/read docs to understand the subtle difference between scheduled start and actual start. Also, "guaranteed period" is a feature; "prevent_drift" is a bug fix.
Can't existing behaviour be achieved by defaulting to guaranteed period or whatever to call it?

[Anthony]

On Tuesday, January 14, 2014 2:58:20 AM UTC-5, Niphlod wrote:

+1. To me is more obvious expecting the actual behaviour than the newly requested when queueing task with "period" and "repeat" but I guess I'm remaining the only one  

I'm not sure either behavior is more obvious. If you don't consider the fact that there will be a lag between the scheduled start and the actual start, the current behavior would probably be surprising. Even if you're aware of the lag, though, I wouldn't automatically assume the current behavior. I suspect that for relatively short periods (i.e., a few minutes), the current behavior will typically be desired (or at least it won't matter either way), but for relatively long periods (i.e., hours, once a day, etc.), having precisely fixed start times will typically be preferred. If you schedule something at 2:00 am with a 24 hour period, you're probably saying you want this to happen every day at 2:00 am, not that you simply want it to happen every 24 hours and don't care about the time of day.

Anthony

[Tim Richardson]

It just sounds like a bugfix if you didn't get how scheduler was meant to be :-P

It's not a bug because it behaves as documented, that's why it is perhaps a very minor shame to make it sound like one. It is however not merely a first world problem, it's a 1% problem.
I have a once-a-day big data load in one app which needs to run at night, so this addition avoiding "sidereal drift" is great. Perhaps we should now claim web2py is realtime :)
lt;dr: "A rose by any other name would smell as sweet".

 

[Simon Ashley]

Has always been an issue with scheduling in our maintenance management systems. We have an additional field with 2 states, fixed or floating. Fixed means that the time is set by the interval plus time when last scheduled. Floating from when the task was actually completed (run). Fixed is normally for statutory requirements, floating for general servicing etc ...

[Niphlod]

ok then, nice discussion. All aboard with prevent_drift ?

thesaurus findings on synonyms of drift....
avoid, forbid, limit, stop....

[Tim Richardson]

yes

--

-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---
You received this message because you are subscribed to a topic in the Google Groups "web2py-developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/web2py-developers/68nGdKAmGmg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to web2py-develop...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Brian Meredyk]

Yes

[massimo....@gmail.com]

yes


From my Android phone on T-Mobile. The first nationwide 4G network.

-------- Original message -------- Subject: Re: [web2py-dev] Re: scheduler: feature request From: Niphlod To: web2py-d...@googlegroups.com CC:

ok then, nice discussion. All aboard with prevent_drift ?

thesaurus findings on synonyms of drift....
avoid, forbid, limit, stop....

On Wednesday, January 15, 2014 7:56:03 AM UTC+1, Simon Ashley wrote:

Has always been an issue with scheduling in our maintenance management systems. We have an additional field with 2 states, fixed or floating. Fixed means that the time is set by the interval plus time when last scheduled. Floating from when the task was actually completed (run). Fixed is normally for statutory requirements, floating for general servicing etc ...

--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---

You received this message because you are subscribed to the Google Groups "web2py-developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to web2py-develop...@googlegroups.com.

[Niphlod]

took me some time mostly to refresh/adapt tests.
https://github.com/web2py/web2py/pull/357
As usual, w2p_scheduler_tests has been updated too.
https://github.com/niphlod/w2p_scheduler_tests

[Tim Richardson]

I sent a book patch.