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

New handler for list results #285

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from
Draft

Conversation

whyscream
Copy link
Contributor

@whyscream whyscream commented Nov 25, 2022

A heavily simplified class to wrap the results of .list() calls. Has cleaner code, implements autopagination handling, and no more features that actually shouldn't be there. See commit message for details.

This should solve #278

@whyscream whyscream force-pushed the 278-new-list-handler branch from 975c50f to 2fc3eb8 Compare November 25, 2022 12:46
@whyscream whyscream force-pushed the 278-new-list-handler branch 3 times, most recently from 96548cf to 11f0fcc Compare December 4, 2022 01:46
@whyscream whyscream changed the title WIP: New list result wrapper New handler for list results Dec 4, 2022
Tom Hendrikx added 3 commits June 20, 2023 12:31
The current result list wrapping class `ObjectList` is intended for list handling,
but supports a mix of list- and  dictionary-related protocols: iteration, slices,
getitem (by key, not by position), etc.

One feature that you'd expect from a list that isn't supported, is getting quickly
from the start to the end of the list. You need to use a combination of `.has_next()`
and `.get_next()` to work through all (paginated) list items.

The old `Objectlist` supports key-based access to its members, but since the data is
paged, you can never be sure that the data is actually available in this page, or in
the next/previous one). Getting list length is also supported, but it only returns
the length of the current page, not a grand total. Both features are treacherous.

To improve on this, a new simple iterator-based approach was used, which transparently
fetches additional paginated data from the API. Things like `getitem` and `len()` are
no longer available, if you need these, they're easy to implement in custom code:

```python
    payments = client.payments.list()
    length = 0
    for item in payments:
        length += 1
        # Equivalent of payments["tr_12345"]
        if item.id == "tr_12345":
            break

    # Equivalent of len(payments)
    print(length)

    # An even better replacement for getting a specific payment would be:
    client.payments.get("tr_12345")
```

TODO:
- More tests
- Reversed() iterator, hoe does it work?
- Add logic to return an ResultListIterator where now an ObjectList is hardcoded
- Empty list results?
@whyscream whyscream force-pushed the 278-new-list-handler branch from 11f0fcc to 4eaf710 Compare June 20, 2023 10:32
@whyscream
Copy link
Contributor Author

After the work in #333 , we need to see what parts of this work are still relevant. Replacing get_next() and get_previous() with automatic pagination handling still seems useful.

@whyscream
Copy link
Contributor Author

Idea from mollie/mollie-api-php#701, add a separate iterator() method for the new implementation, in stead of a parameter for the list() method

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

Successfully merging this pull request may close these issues.

1 participant