Implement Standalone Convert; Enum Handling; User Edge/Connection Classes; Column Alias Handling

[gravy-jones-locker]

Description

This includes a number of changes, including:

1. mapper.type now calls mapper.convert - this allows mapper.convert to be called within user code, which makes the relevant functionality accessible where a decorator is not appropriate.
2. strawberry.enum is called against SQLAlchemy Enum columns.
3. Rather than relying on dynamically generated, model specific classes, the user can now pass Edge and Connection classes to the mapper constructor. This is necessary where those Edge/Connection classes are used elsewhere in user schemas.
4. Relationship mapping is updated such that user-defined column names are taken into account rather than just model attribute names.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Documentation

Issues Fixed or Closed by This PR

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).

[Ckk3]

up

[mattalbr]

Thanks for the change! I'm still new on the project, so I left a few comments but added Tim and Erik as reviewers for their expertise.

If you could also add a RELEASE.md file, pushing a new commit should trigger all of the new automated testing that I got working this week (feel free to ignore the Lint step which I haven't gotten green yet).

[mattalbr]

From my reading of strawberry.enum it should be okay to wrap a type twice, but it would be great to have a test that does this. E.g. in my company, we already annotate all of our enums with @strawberry.enum, and I'm unsure if that would set python_type to the wrapped or unwrapped enum, and what would happen here.

Just a test that does

@strawbery.enum
class MyEnum(enum.StrEnum):
  FOO = "FOO"

class MyModel(Base):
  my_enum = Column(Enum(MyEnum))

[asimov-layton]

Another thought for the tests: what does that second wrapping do to any of the initial settings? e.g. If I @strawberry.enum(name="DifferentName") does it still respect the overwritten name?

[mattalbr]

Added Erik to comment on this, but we should probably at the very least have a Protocol that these types should follow

[mattalbr]

I think if this is to be part of the public API, we should probably beef up the docstring a bit. I still don't really understand when someone would need this, and why someone wouldn't just call Employee = mapper.type(models.Employee)(Employee)

At the least, exercising this in a unit test to have some basic API-level test coverage and demonstrate the usage could be nice, but might be worth waiting until Erik or Tim weighs in.

[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 :)

[TimDumol]

1. Change PR title and description? Seems to only have the edge/connection type changes
2. It's been a while since I've touched this code, but don't we need a distinct edge / connection type for each relationship (or at least, node type in a relationship)? e.g., if Book -> Authors and Book -> Reviews, you'd need a different edge / connection type for Author and Review, which this doesn't seem to support.

[erikwrede]

Hey, let's delay the enum part of this until we've standardized strawberry-graphql/strawberry#3543
This will allow us to just use any enum and have strawberry's core logic handle the rest.