graphql-python / graphql-python/graphene

Implement property-style Graphene fields

未关闭
#1,301 2 条评论 1 个 reaction 已指派 0 人 在 GitHub 查看
✨ enhancement
主要语言
Python
星标
8.2k
派生
818
PR 合并指标
30 天内没有已合并 PR

描述

**Is your feature request related to a problem? Please describe.**
I am trying to learn how to use Graphene with my existing DataModels. The problem I've come across is my use of python's `@property` decorator. My DataModel uses these to ensure proper logic when new attributes are set, and only allowing certain ones to be used. With Graphene's implementation, I am expected to define my properties as *attributes* instead, which eliminates my ability to use logic when a property is set, or decide which properties can be set at all.

The documentation does explain that Graphene objects can be used as real data-retaining objects, but I am not willing to sacrifice my current inheritance and implementation for a simple `ObjectType` class implementation.

Additionally, the documentation also explains that any [dictionary-like object can be used to lookup attributes with the same name](https://docs.graphene-python.org/en/latest/types/objecttypes/#defaultresolver), but now I am tasked with maintaining an additional class just to build the schema. I would prefer to keep my definition as tightly coupled to my actual implementation as I can, meaning I want to define it directly in my data-model.

**Describe the solution you'd like**
I want a way to integrate Graphene's schema building with my model's **properties**. I would prefer not to write custom resolvers and specially name all of the attributes I want to expose. Perhaps a decorator approach could be used
```python3
@property
@graphene_property(type=String, name="custom_name", desc="This is a property-based graphene field")
def serial(self):
...
```
I imagine this decorator can be a subclass of `Field` from `graphene.types.field`. Maybe a name like `@property_field` better suits this. I am definitely willing to try and open a PR for this, but I wanted to have some initial discussion first. I want to explore this later using a descriptor.

**Describe alternatives you've considered**
I am currently not using Django, but I've considered investing more into the Django stack only to be able to use the additional `Meta` class option of `model`. I have not done enough research, and adopting the entire Django stack into my program is **not** what I'd like to do.

**Additional context**
I am currently **not** using Django. I would not like to implement it to fix this problem.

If you can think of a way that works around this issue without implementing a new feature, I'd be happy to discuss. I don't know the ins and outs of Graphene, and I want to express this all very humbly. Please let me know if I'm horribly overlooking something, or you believe my implementation is bonkers. Thanks for your time!

贡献指南

这个仓库没有索引到贡献指南

调研方向

先查看 Graphene 文档中关于默认 resolver 行为的说明以及 graphene.types.field 中的 Field 类,然后比较拟议的属性装饰器方案和描述符方案。该 issue 需要在实现之前确定 API 和验收标准;完成的标准是模型属性无需自定义 resolver 或 Django 即可参与 schema 构建。

由索引模型根据 Issue 内容生成。

评估

技术栈
python
领域
api, backend
Issue 类型
功能
难度
5/5
预计耗时
一周以上
活跃度
停滞
描述清晰度
需要澄清
新手友好度
25/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。