Skip to content

doc-gen: Migrate windows functions from code based documentation to attribute based #13670

Closed

Description

@comphead

Is your feature request related to a problem or challenge?

It is needed to migrate whenever it is possible window UDF documentation from code based to attribute based.

Function list can be found in SessionStateDefaults::default_window_functions()

Example can be found https://github.com/apache/datafusion/pull/13646/files#diff-1528bf73810e3fb12fd1d4e76a8b46acb650549ef37d3c131464e087f97ca515L25

The translation can be done manually or in semi automatic way, uncommenting a function in PR #13669 locally. This will generate local text files with attribute text which can be copy pasted to structs. However its still needed to remove code based documentation manually, add imports, etc

Please refer to PR #13646 which completed the migration for aggregation functions

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Additional context

No response

Activity

  1. zjregee commented on Dec 9, 2024

    @zjregee
    Member

    take

  2. zjregee commented on Dec 11, 2024

    @zjregee
    Member

    Hi, @comphead, I'm confused on how to handle the following situation, can you give me some advice?

    impl WindowUDFImpl for NthValue {
        fn documentation(&self) -> Option<&Documentation> {
            match self.kind {
                NthValueKind::First => Some(get_first_value_doc()),
                NthValueKind::Last => Some(get_last_value_doc()),
                NthValueKind::Nth => Some(get_nth_value_doc()),
            }
        }
    }

    Taking NthValue as an example, it implements different window functions through the enumeration value of its own type. How should I add user_doc for it? Do I need to modify user_doc itself to support this scenario?

  3. comphead commented on Dec 11, 2024

    @comphead
    ContributorAuthor

    Hi, @comphead, I'm confused on how to handle the following situation, can you give me some advice?

    impl WindowUDFImpl for NthValue {
        fn documentation(&self) -> Option<&Documentation> {
            match self.kind {
                NthValueKind::First => Some(get_first_value_doc()),
                NthValueKind::Last => Some(get_last_value_doc()),
                NthValueKind::Nth => Some(get_nth_value_doc()),
            }
        }
    }

    Taking NthValue as an example, it implements different window functions through the enumeration value of its own type. How should I add user_doc for it? Do I need to modify user_doc itself to support this scenario?

    For cases like that let's leave it as is.
    I also faced the same scenario with invariants for aggregated functions, I dont think we can do much about it.

    My understanding we can migrate 90%-ish of documentation to attributes still allowing for developers to implement API approach.

    Perhaps in future we can expand user_doc and support enums but now it would be slightly prematurely

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

documentationImprovements or additions to documentationenhancementNew feature or requestgood first issueGood for newcomers

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions