Thanks for proposing a pull request. Adding Limit doesn't align well with the intent of this interface definition as ReactiveSortingRepository expresses sort capabilities. Also, implementing a default method using take creates a risk of fully loading all data. This will come as a surprise to users and can easily generate incidents. Therefore, we do not plan to merge this pull request and recommend using query derivation using Limit for the time being.

@mp911de
Thank you for reviewing my pull request and for the feedback provided. I understand the concerns about aligning with the interface's intent and the potential risks associated with the default implementation using take that could lead to loading all data into memory unexpectedly.

Before I move on from this, I would like to clarify a few points to ensure that I fully understand the project's direction and to contribute effectively in the future:

1. Is the main concern that introducing a limit parameter does not fit well with the ReactiveSortingRepository interface's intended purpose, which is to focus solely on sorting capabilities?

2. If the addition of a limit parameter itself is not the issue, is the concern primarily with the default method's implementation that uses take? In that case, would an alternative implementation like the following be more aligned with the project's standards?

return findAll(sort)
    .handle((t, sink) -> {
        if (sink.requestedFromDownstream() > 0) {
            sink.next(t);
        }
    })
    .limitRequest(maxLimit);

3. If neither the above concern addresses the core issue, could you please provide some guidance or a sample of the preferred implementation approach? It would be greatly beneficial to understand the direction in which we wish to take the repository capabilities, especially concerning limiting the result set.

Your insights will be invaluable for guiding future contributions and ensuring they are in line with the project's goals.

Thank you for your time and consideration.