I've just published the draft AIP for discussion - please comment on
that thread, or on the AIP directly
<https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-39+Richer+scheduler_interval>
<https://lists.apache.org/thread.html/rf8eeb06493681f48dc9e82ce605a9c3a930cfee0b4ca19462a4e55b3%40%3Cdev.airflow.apache.org%3E>
Thanks for all your input everyone!
-ash
On Tue, 23 Feb, 2021 at 10:26, Ash Berlin-Taylor <a...@apache.org> wrote:
That is exactly the approach I am working on an AIP for -- I hope to
have it out (at least in draft/discussion form) this week.
-ash
On Tue, 23 Feb, 2021 at 00:39, Dmitri Khokhlov <dkhokh...@gmail.com>
wrote:
ok, how about this:
1) implement "function" approach first. solve all plumbing & ui.
2) then implement "multiple crons" approach using 1).
that way users potentially can use 2) as reference implementation to
create their own custom extensions based on 1).
--
Dmitri
On 2021/02/17 15:47:01, Phil Yardley <p...@dunnhumby.com
<mailto:p...@dunnhumby.com>> wrote:
> Is it possible to offer both? (maybe in two releases)..>
>
> that then allows the user to select the most appropriate for their
scenario. >
>
> My scenario for example is easy with multiple crons:>
>
> Monday - Thursday run job A at 9pm>
> Friday - run job A at 8pm>
>
> this is easier in cron than writing a python extension to handle
it.>
>
> But - having the ability to write a custom method in language x
then satisfies those that need something more complex such as the
astronomy example in the thread.>
>
> "it looking complicated" to the user, is probably for the user to
worry about - if it looks too complicated, they've probably selected
the wrong way of doing it. (or chosen the simplest and not worried
about how it looks)>
>
> Phil>
>
>
> On 2021/01/24 07:04:03, Jarek Potiuk <ja...@potiuk.com
<mailto:ja...@potiuk.com>> wrote: >
> > Yep. I agree with Daniel - adding multiple crons is very
difficult to>
> > reason about. you can create arbitrary complex declarative way
of defining>
> > complex schedule that you will have hard time understanding. We
are>
> > already entering the realm of programming the schedule, which I
