Release 2.2.0

What's Changed

• fix: avoid "lookup was already seen with a different queryset" by merging existing prefetches together with hints (#192)
• Add missing demo migration by @Mapiarz in #191
• Add support for field extensions. by @pcraciunoiu in #194

New Contributors

• @Mapiarz made their first contribution in #191
• @pcraciunoiu made their first contribution in #194

Full Changelog: v2.1.0...v2.2.0

Release 2.1.0

What's changed

• refactor: use the new extension style using on_execute
• fix: fix optimizer not working on some cases with fragment spreading
• feat: start testing on Django 4.2
• fix: fix relay connections not being optimized

Full Changelog: v2.0.6...v2.1.0

Release 2.0.6

What's Changed

• Bump strawberry-graphql to 0.161.0 and fix import error by @mumumumu in #183

New Contributors

• @mumumumu made their first contribution in #183

Full Changelog: v2.0.5...v2.0.6

Release 2.0.5

What's Changed

• fix: fix typing for update/delete mutations
• chore(deps-dev): bump ipython from 8.9.0 to 8.10.0 by @dependabot in #175
• chore: migrate to ruff for linting

New Contributors

• @dependabot made their first contribution in #175

Full Changelog: v2.0.4...v2.0.5

Release 2.0.4

What's Changed

• fix handling of strawberry.Private (lazy) by @devkral in #171

Full Changelog: v2.0.3...v2.0.4

Release 2.0.3

What's changed

• fix(django-relay): fix filter/order not being applied to django relay connections

Full Changelog: v2.0.2...v2.0.3

Release 2.0.2

What's changed

• fix(relay): fix support for custom resolvers returning generators

Full Changelog: v2.0.1...v2.0.2

Release 2.0.1

What's Changed

• fix: django connection field resolve_connection args by @OdysseyJ in #168

Full Changelog: v2.0...v2.0.1

Release 2.0

What's Changed

• BREAKING CHANGE: Relay refactor by @bellini666 in #167

Relay BREAKING CHANGES

The relay integration has been refactored to simplify its usage and allow for better customization.

If you were not defining any custom Connection/Edge types, this should not affect you! Otherwise, follow this directions to adjust your code:

1. The Node.resolve_connection classmethod has been removed. If you want to personalize how the connection is created and filtered, you can subclass the Connection class and override the from_nodes classmethod

2. The Node.CONNECTION_CLASS and Connection.EDGE_CLASS are gone! The connection class will be retrieved from the type itself. For example, this will use CustomConnection for the some_connection field:

@strawberry.type
class CustomConnection(relay.Connection[relay.NodeType]):
    ...

@strawberry.type
class Query:
    some_connection: CustomConnection[SomeType] = relay.connection()

3. The relay resolver (when using it as a @relay.connection) accepts both an iterable of a node implemented type or a connection directly. For example:

@strawberry.type
class Query:
    @relay.connection
    def some_connection(self, some_extra_arg: str) -> Iterable[SomeType]:
        ...

    @relay.connection
    def some_connection(self, first: int | None = None, last: int | None = None, ...) -> Connection[SomeType]:
        ...

Both will return a SomeTypeConnection, but in the iterable one you just need to give it the iterable itself and the connection will filter it with slices for you. In the second example you are responsible for paginating it yourself.

obs. That iterable have its __getitem__ overrided for custom slicing. For example, when returning a django QuerySet the slice will translate to a limit/office in the query and retrieve just the paginated items for better performance.

Full Changelog: v1.35.2...v2.0

Release 1.35.2

What's changed

• fix(mutations): ensure that pk is not added by the django base field in create/update/delete mutations (#165)

Full Changelog: v1.35.1...v1.35.2