Unblock strawberry upgrade to 0.243.1

[mattalbr]

Strawberry reorganized a lot of its types, so this is just a no-op that changes a bunch of import paths.

Issues Fixed or Closed by This PR

• Closes #189

Checklist

• [ ] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [ ] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.
• [ ] I have tested the changes and verified that they work and don't break anything (as well as I can manage).

Summary by Sourcery

Unblock the upgrade to Strawberry 0.243.1 by updating import paths and adapting to changes in type definitions.

Enhancements:

• Update import paths to align with the reorganization of types in Strawberry 0.243.1.

[sourcery-ai[bot]]

Reviewer's Guide by Sourcery

This pull request updates the codebase to accommodate changes in the Strawberry library's type organization. The changes are primarily import path updates and minor adjustments to how Strawberry's internal structures are accessed, with no functional changes to the application logic.

No sequence diagrams generated as the changes look simple and do not need a visual representation.

File-Level Changes

Change	Details	Files
Update access to Strawberry's internal structures	Change 'strawberry_definition__._fields' to 'strawberry_definition__.fields' Update assertions to use the new field access method	tests/test_mapper.py
Modify BigInt scalar definition	Import 'NewType' from typing module Wrap Union[int, str] with NewType in BigInt scalar definition	src/strawberry_sqlalchemy_mapper/scalars.py
Update import path for Strawberry types	Change import of 'StrawberryContainer' and 'get_object_definition' from 'strawberry.type' to 'strawberry.types.base'	src/strawberry_sqlalchemy_mapper/relay.py

---

Tips and commands

#### Interacting with Sourcery - **Trigger a new review:** Comment `@sourcery-ai review` on the pull request. - **Continue discussions:** Reply directly to Sourcery's review comments. - **Generate a GitHub issue from a review comment:** Ask Sourcery to create an issue from a review comment by replying to it. #### Customizing Your Experience Access your [dashboard](https://app.sourcery.ai) to: - Enable or disable review features such as the Sourcery-generated pull request summary, the reviewer's guide, and others. - Change the review language. - Add, remove or edit custom review instructions. - Adjust other review settings. #### Getting Help - [Contact our support team](mailto:support@sourcery.ai) for questions or feedback. - Visit our [documentation](https://docs.sourcery.ai) for detailed guides and information. - Keep in touch with the Sourcery team by following us on [X/Twitter](https://x.com/SourceryAI), [LinkedIn](https://www.linkedin.com/company/sourcery-ai/) or [GitHub](https://github.com/sourcery-ai).

[botberry]

Hi, thanks for contributing to Strawberry 🍓!

We noticed that this PR is missing a RELEASE.md file. We use that to automatically do releases here on GitHub and, most importantly, to PyPI!

So as soon as this PR is merged, a release will be made 🚀.

Here's an example of RELEASE.md:

Release type: patch

Description of the changes, ideally with some examples, if adding a new feature.

Release type can be one of patch, minor or major. We use semver, so make sure to pick the appropriate type. If in doubt feel free to ask :)

[codspeed-hq[bot]]

CodSpeed Performance Report

Merging #191 will not alter performance

_{Comparing mattalbr:upgrade_strawberry (2974a3c) with main (f9c09a1)}

Summary

✅ 1 untouched benchmarks

[Ckk3]

Hi @mattalbr, I noticed that this PR seems to duplicate the work in #187. It wasn’t immediately clear because the first PR was opened before the issue, so the issue came up without a linked PR.

Since you have more experience with this project, what do you think is the best course of action? Should we prioritize the later PR?

[mattalbr]

Hi @mattalbr, I noticed that this PR seems to duplicate the work in #187. It wasn’t immediately clear because the first PR was opened before the issue, so the issue came up without a linked PR.

Since you have more experience with this project, what do you think is the best course of action? Should we prioritize the later PR?

Amazing, I missed #187! Assuming the author of #187 is responsive to the few tweaks we need for the latest version, I would definitely prefer we go with their PR! It never feels good to have your PR swooped :)

Closing for now, I'll reopen if we stall on #187.