Kyungjun: > dataflow graphs, event-driven DAGs, or asset-based workflows
I think you would have to clarify what you are asking for. I believe (depending on the definition of all three), Airflow already supports all three things you mentioned. Many of the things we implemented in Airflow 3 went way beyond the "traditional task dependency graph" and Airflow 3 moved from dataset to asset, implemented new asset centric syntax, implemented external asset-driven scheduling. And we have few AIPs in progress like asset watermarks, partitioning etc. > but I hope it’s okay to ask here. I think it has very little to do with this discussion, so if you want to continue asking questions about asset driven things - possibly look at the current docs and ask questions you have separately (GitHub Discussions, Slack) - I think we do not want to have a tangential discussion starting here. It's a mistake that everyone (including myself) can make - it derails the discussion and muddies the waters if you try to discuss different topics in the same thread, so we should avoid this. J. On Thu, Sep 4, 2025 at 12:17 AM Daniel Standish <[email protected]> wrote: > First we must arrive at something approaching consensus, which it seems we > have not ;) > > On Wed, Sep 3, 2025 at 4:14 PM Ferruzzi, Dennis > <[email protected]> > wrote: > > > > I believe we should better document the decision this time. > > > > Hate to be That Guy, but what about (yet another) prek rule to enforce > it? > > > > > > - ferruzzi > > > > > > ________________________________ > > From: Kyungjun Lee <[email protected]> > > Sent: Tuesday, September 2, 2025 5:46 PM > > To: [email protected] > > Subject: RE: [EXT] [DISCUSS] dag vs DAG vs Dag > > > > CAUTION: This email originated from outside of the organization. Do not > > click links or open attachments unless you can confirm the sender and > know > > the content is safe. > > > > > > > > AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. > > Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne > pouvez > > pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain > que > > le contenu ne présente aucun risque. > > > > > > > > This may be a slightly different topic from the current discussion, but I > > hope it’s okay to ask here. Are there any ongoing or planned discussions > > within the community about extending the concept of DAGs beyond the > > traditional “task dependency graph” definition — for example, toward > > dataflow graphs, event-driven DAGs, or asset-based workflows? > > > > > > > > 2025년 9월 2일 (화) 오후 8:53, Jarek Potiuk <[email protected]>님이 작성: > > > > > > “If you name it, you can own it > > > > > > Yep. 100%. Precisely what Ash wrote. I am actually quite happy that > many > > > people say "this is something that is not correct". In a way it makes > it > > a > > > perfect candidate to pick someone we can "own" - because nobody owns it > > yet > > > in the minds of people. > > > The fact that we feel uncomfortable about it "now" is exactly the > reason > > > why we should choose it. > > > Mostly because this is something that we claim "ownership" of - and (as > > > with everything) we will get used to it over time and we will start > > > treating it as ours if we accept it as "our" term. > > > > > > J. > > > > > > On Tue, Sep 2, 2025 at 11:38 AM Ash Berlin-Taylor <[email protected]> > > wrote: > > > > > > > “If you name it, you can own it” > > > > > > > > +1 for Dag, it can be an airflow term, much more so than DAG as an > > > acronym > > > > can be. > > > > > > > > > On 2 Sep 2025, at 08:03, Ankit Chaurasia <[email protected]> > > wrote: > > > > > > > > > > I totally agree that "Dag" - it is neither a proper class nor a > > proper > > > > > variable naming pattern. > > > > > > > > > > "DAG" can be used when referring directly to the class. > > > > > > > > > > "dag" makes the most sense as it aligns with Python’s snake_case > for > > > > > identifiers. > > > > > > > > > > *Ankit Chaurasia* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Sep 1, 2025 at 11:23 PM Sumit Maheshwari < > > > [email protected] > > > > > > > > > > wrote: > > > > > > > > > >> 100% agree with Daniel. "Dag" seems to be the worst choice out of > > all > > > > >> options. > > > > >> > > > > >> > > > > >> On Mon, Sep 1, 2025 at 10:54 PM Daniel Standish > > > > >> <[email protected]> wrote: > > > > >> > > > > >>> I sort of don't really understand why we would write Dag. It > seems > > > > >>> kindof the worst of both worlds. That's not what the class is. > > And > > > it > > > > >>> doesn't really make sense as a proper noun. > > > > >>> > > > > >>> I would just use dag most of the time and DAG when you need to > > refer > > > > >>> unambiguously to the actual class. > > > > >>> > > > > >>> > > > > >>> On Sun, Aug 31, 2025 at 3:46 PM Jarek Potiuk <[email protected]> > > > wrote: > > > > >>> > > > > >>>> I don't think we concluded whether we should use "Dag" or > "dag" - > > > but > > > > >> I > > > > >>>> think the important goal of why we decided on dropping the "DAG" > > as > > > > >>> acronym > > > > >>>> was that we want to really start "owning" the "Dag" term - "Dag" > > > > really > > > > >>>> meaning "Airflow Workflow". > > > > >>>> I think using capitalized form "Dag" fulfills that goal better > > than > > > > >>> "dag". > > > > >>>> > > > > >>>> J. > > > > >>>> > > > > >>>> > > > > >>>> On Sun, Aug 31, 2025 at 5:09 PM Pierre Jeambrun < > > > > [email protected] > > > > >>> > > > > >>>> wrote: > > > > >>>> > > > > >>>>> Response thread there. Can’t remember the full outcome from the > > top > > > > >> of > > > > >>> my > > > > >>>>> head but “Dag, dag, dags” seems fine, preferably for doc, new > > code, > > > > >>> user > > > > >>>>> facing, but not worth the trouble going through the whole > > codebase > > > > >> for > > > > >>>>> refactoring. > > > > >>>>> > > > > >>>>> > > > > >>>>> > https://lists.apache.org/thread/8k338stlkkp07ko3no70p2nng757kd1w > > > > >>>>> > > > > >>>>> On Sun 31 Aug 2025 at 17:01, Wei Lee <[email protected]> > > wrote: > > > > >>>>> > > > > >>>>>> I think our previous consensus was “dag" or “dags", but recent > > > PRs, > > > > >>>>>> including mine, have changed them to "Dag". I’m fine with > "Dag" > > or > > > > >>>> “dag” > > > > >>>>>> (like “dag” a bit more) as long as it’s not “DAG”. > > > > >>>>>> > > > > >>>>>> I believe we should better document the decision this time. I > > can > > > > >>>> create > > > > >>>>>> that PR once we finalize it again here. > > > > >>>>>> > > > > >>>>>> Best, > > > > >>>>>> Wei > > > > >>>>>> > > > > >>>>>>> On Aug 31, 2025, at 9:13 PM, Daniel Standish > > > > >>>>>> <[email protected]> wrote: > > > > >>>>>>> > > > > >>>>>>> Saw this PR https://github.com/apache/airflow/pull/55097 > > > > >>>>>>> > > > > >>>>>>> I thought we discussed this at some point that using just > "dag" > > > > >> or > > > > >>>>> "dags" > > > > >>>>>>> is perfectly fine. De-emphasizing the mathy origin of the > > "DAG" > > > > >>>>> concept. > > > > >>>>>>> > > > > >>>>>>> Personally I believe we should leave instances of "dag" or > > "dags" > > > > >>> in > > > > >>>>> the > > > > >>>>>>> docs alone. > > > > >>>>>>> > > > > >>>>>>> Is the consensus I recall just an invention of my mind? > > > > >>>>>>> > > > > >>>>>>> Thanks > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >> > > --------------------------------------------------------------------- > > > > >>>>>> To unsubscribe, e-mail: [email protected] > > > > >>>>>> For additional commands, e-mail: [email protected] > > > > >>>>>> > > > > >>>>>> > > > > >>>>> > > > > >>>> > > > > >>> > > > > >> > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > >
