2 ms·

Replying to each of your points: 1. I completely agree. We have recently acknowledged the power in an "alien" syntax as you put it. In v2.0.0 Odin will also su

by ojs 6y ago

Replying to each of your points: 1. I completely agree. We have recently acknowledged the power in an "alien" syntax as you put it. In v2.0.0 Odin will also support the classic cron schedule string syntax! 2. You are right, the repo is lacking a detailed description on this. The execution semantics boils down to at most once. 3. The Yaml file just lends some simple schedule and runtime info to the job. We actually would rather this moved into the code in v2.0.0 - that way all workflow info is self contained and no supplementary files are needed. The multiple data store thing is entirely an issue, in v.2.0.0 we are aiming to make more aspects (such as you have described) pluggable, using whatever data stores you specify. That will require a lot of docs but we are up to task. That you so much for the advice comments, I will share them with the development team, feedback is always appreciated :)

boulos 6y ago
The original App Engine Cron had its own "human friendly" format for the schedule argument [1]. The problem is that what people want to copy/paste from the internet is some form of vixie-cron usually. However, all cron formats are subject to lots of ... edge cases depending on what you think of as normal. For example, since Vixie cron (and its descendants) are pattern matchers, there isn't a way to express "Run this every 33 minutes". Even a "sane schedule" gets to have fun with timezones and their adjustments (both for daylight savings but also countries adjusting their rules). Airbnb's Chronos chose instead to use ISO 8601 Repeating Intervals [2] which in written form are R[n]/<timestamp>/<period> (where n is the number of repetitions and timestamp is the start time). That's a good format for an infinitely repeating thing with arbitrary period, but not able to actually express "at 6PM every weekday" (which crons do, and many humans want). Finally, all repeating schedules go out the window once you get to someone who probably needs something more explicit: every NASDAQ trading day after market close (which is usually 4:30 but sometimes not, not open every weekday, etc.). The usual answer is "Just make the schedule to run every weekday at 1 PM Eastern for the early closes and usually exit, every weekday at the usual 4PM Eastern and have your code check that the market isn't on holiday". The same kind of works for the 33-minute period, except the answer ends up being "check every minute and do your own modulus to figure out if you should run" (which isn't particularly helpful). Enjoy scheduling! [1] https://cloud.google.com/appengine/docs/standard/python/config/cronref#schedule_format https://cloud.google.com/appengine/docs/standard/python/conf... [2] https://en.wikipedia.org/wiki/ISO_8601#Repeating_intervals https://en.wikipedia.org/wiki/ISO_8601#Repeating_intervals

by ojs 6y ago

boulos 6y ago

The original App Engine Cron had its own "human friendly" format for the schedule argument [1]. The problem is that what people want to copy/paste from the internet is some form of vixie-cron usually. However, all cron formats are subject to lots of ... edge cases depending on what you think of as normal. For example, since Vixie cron (and its descendants) are pattern matchers, there isn't a way to express "Run this every 33 minutes". Even a "sane schedule" gets to have fun with timezones and their adjustments (both for daylight savings but also countries adjusting their rules). Airbnb's Chronos chose instead to use ISO 8601 Repeating Intervals [2] which in written form are R[n]/<timestamp>/<period> (where n is the number of repetitions and timestamp is the start time). That's a good format for an infinitely repeating thing with arbitrary period, but not able to actually express "at 6PM every weekday" (which crons do, and many humans want). Finally, all repeating schedules go out the window once you get to someone who probably needs something more explicit: every NASDAQ trading day after market close (which is usually 4:30 but sometimes not, not open every weekday, etc.). The usual answer is "Just make the schedule to run every weekday at 1 PM Eastern for the early closes and usually exit, every weekday at the usual 4PM Eastern and have your code check that the market isn't on holiday". The same kind of works for the 33-minute period, except the answer ends up being "check every minute and do your own modulus to figure out if you should run" (which isn't particularly helpful). Enjoy scheduling! [1] https://cloud.google.com/appengine/docs/standard/python/config/cronref#schedule_format https://cloud.google.com/appengine/docs/standard/python/conf... [2] https://en.wikipedia.org/wiki/ISO_8601#Repeating_intervals https://en.wikipedia.org/wiki/ISO_8601#Repeating_intervals