Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow method chaining in Processor.Builder #910

Open
gregorko opened this issue Nov 15, 2024 · 3 comments
Open

Allow method chaining in Processor.Builder #910

gregorko opened this issue Nov 15, 2024 · 3 comments
Labels

Comments

@gregorko
Copy link

Description

Return type of methods in Processor.Builder prevent method chaining.

Example:

co.elastic.clients.elasticsearch.ingest.Processor.of(b -> b
    .attachment(a -> a)
    .remove(r -> r)
)

This will not compile since attachment() and all other methods return ObjectBuilder<Processor> instead of Builder

@l-trotta
Copy link
Contributor

Hello! The reason why Processor doesn't allow chaining is that APIs that use it usually require a List<Processor>, so that's how you can set multiple processors. Is there a specific case where you would use multiple processors outside a list? Or could you point me to the API you're trying to use? Maybe there's a case we missed, let me know!

@gregorko
Copy link
Author

This is how I use it now:

        client.ingest().putPipeline(b -> b
            .processors(p -> {
                    p.attachment(a -> a);
                    p.remove(r -> r);
                    return p;
                }));

but compared to other APIs it would feel more natural to use it like this:

        client.ingest().putPipeline(b -> b
            .processors(p -> p
                    .attachment(a -> a)
                    .remove(r -> r);
            ))

@l-trotta
Copy link
Contributor

Hmm I get it now, it does feel more natural. The issue we have with implementing this is that it's a significant change to the client code generator, and we'd also need to evaluate how it would affect similar classes, so we'll evaluate this as a possible enhancement!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants