Discussion: decoupling async data loading from async graph resolution
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 25/100
- Issue 类型
- 功能
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
- 技术栈
- graphql, python
调研方向
从 asyncio main() 示例和 graphql(schema, query, context_value=context) 调用开始。跟踪 async EStopHMI 和 JogHMI resolver 是如何被调度的,以及它们的 awaitable 是如何处理的。该 issue 要求一种将叶数据发现、获取和最终结果解析分离开的设计;未指定具体的实现文件或测试。
由索引模型根据 Issue 内容生成。
描述
TLDR: I would like graph-core to tell me what "leaf" nodes from my query need returned. Allow me to fetch the data through whatever method I deem efficient. Then I would like graph-core to take care of returning the data. The current asyncio implementation, seems to fundamentally not work for this.
I've been digging in deep on a graphql-core build recently and have stumbled across this interesting problem. If I've missed a key feature of the library here, than please point it out.
To me, the ideal way to use the core library is to:
- Use graph-core to decide what data to retrieve.
- Use a separate data loading engine to read the data.
- Use graph-core to return the data.
Its interesting to see where this problem fits in as either a graphe-core-3 issue, needing a feature, or a graphql issue. The essential catch is this, it's very hard to determine when the graph-core resolution has finished deciding what leaves from the graph need fetched. Here's an example to illustrate the point.
##########################################################
## TEST GRAPHE SCHEMA BASED ON ASYNCIO ######################
##########################################################
from graphql import (
GraphQLBoolean, graphql, GraphQLSchema, GraphQLObjectType, GraphQLField, GraphQLString)
import logging
import asyncio
_logger = logging.getLogger('GrapheneDeferralTest')
_logger.setLevel('DEBUG')
query = """
{
ioHMIControls {
EStopHMI,
JogHMI,
}
}
"""
async def resolve_EStopHMI(parent, info):
_id = '_EStopHMI_id'
info.context['node_ids'][_id] = None
await info.context['awaitable']
return info.context['node_ids'][_id]
EStopHMI = GraphQLField(
GraphQLBoolean,
resolve=resolve_EStopHMI
)
async def resolve_JogHMI(parent, info):
_id = '_JogHMI_id'
info.context['node_ids'][_id] = None
await info.context['awaitable']
return info.context['node_ids'][_id]
JogHMI = GraphQLField(
GraphQLBoolean,
resolve=resolve_EStopHMI
)
def resolve_ioHMIControls(parent, info):
return ioHMIControls
ioHMIControls = GraphQLObjectType(
name='ioHMIControls',
fields={
'EStopHMI': EStopHMI,
'JogHMI':JogHMI,
}
)
def resolve_GlobalVars(parent, info):
return GlobalVars
GlobalVars = GraphQLObjectType(
name='GlobalVars',
fields={
'ioHMIControls': GraphQLField(ioHMIControls, resolve=resolve_ioHMIControls)
}
)
async def simulate_fetch_data(_ids):
print(_ids)
await asyncio.sleep(1)
return {k:True for k in _ids.keys()}
async def main():
# Objective:
# 1. Have graph determine what data I need by partially resolving
# 2. Pause graph resolution.
# 3. Collect data into a `data_loader` object.
# 4. Retrieve data via `data_loader` object.
# 5. Resume graph resolution with loaded data.
# 3. collect ids of data fields into a dict
_ids = {}
#2. pause graph resolution by awaitn a future
future = asyncio.Future()
context = {
'node_ids': _ids,
'awaitable': future,
}
schema = GraphQLSchema(query=GlobalVars)
# 1. Determine WHAT data to return
resove_graph_task = asyncio.create_task(graphql(schema, query, context_value=context))
# ?
# There is no way to detect that resolve_graph_task
# has finished fillin _ids dict with id values.
# 4. Fetch the data
fetch_data_task = asyncio.create_task(simulate_fetch_data(_ids))
# ?
# This await doesn't work in this order or any order
# becaus of the interdependancy of both tasks, coupled with
# the mechanics of asyncio.
await fetch_data_task
# 5. Resume graph resolution with retrieved data.
future.set_result(0)
# ?
# return the data from the graph, as a graph result.
# problem, is that the data is not there due to
# interdependancy between await tasks.
result = await resove_graph_task
print(result)
if __name__ == '__main__':
asyncio.run(main())
Results
{}
ExecutionResult(data={'ioHMIControls': {'EStopHMI': None, 'JogHMI': None}}, errors=None)
The example is a little long, but I wanted it to be sufficiently complex. The gist is that there is no way in the current asyncio implementation to determine that: all resolvers have been reached.
Looking at the implementations we could use some advanced event systems to manage this, but it would be a bit of work. Another possible solution could be to allow resolvers to return coroutines and put off type checking till those coroutines are themselves resolved. I think, this may be the most elegant method.
Thoughts?
- 主要语言
- Python
- 星标
- 531
- 派生
- 147
- PR 合并指标
- 30 天内没有已合并 PR
贡献指南
这个仓库没有索引到贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
graphql-python/graphql-core 的其他 Issue
-
难度 4/5 3-5 天 新手友好度 50/100
graphql-python/graphql-core#272 · 1 条评论 ·
-
难度 3/5 1-2 天 新手友好度 55/100
graphql-python/graphql-core#269 · 1 条评论 ·
-
难度 5/5 一周以上 新手友好度 35/100
graphql-python/graphql-core#267 · 1 条评论 ·
-
难度 3/5 1-2 天 新手友好度 45/100
graphql-python/graphql-core#257 ·
-
难度 5/5 一周以上 新手友好度 25/100
graphql-python/graphql-core#247 · 8 条评论 ·
查看 graphql-python/graphql-core 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 75/100
anthropics/skills#1811 · 1 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
speaches-ai/speaches#678 ·
-
bug
难度 2/5 1-3 小时 新手友好度 75/100
datalayer/mcp-compose#42 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
conda-forge/spacy-feedstock#177 ·
-
难度 2/5 1-3 小时 新手友好度 70/100
UKGovernmentBEIS/inspect_evals#2523 ·