首页 > 数据库 >使用Pydantic和SqlAlchemy实现树形列表数据（自引用表关系）的处理，以及递归方式处理数据差异

使用Pydantic和SqlAlchemy实现树形列表数据（自引用表关系）的处理，以及递归方式处理数据差异

时间：2024-10-15 19:10:32浏览次数：8  
标签：lazy SqlAlchemy 处理 id ou children Pydantic 加载

在我的设计框架业务中，字典大类、部门机构、系统菜单等这些表，都存在id、pid的字段，主要是作为自引用关系，实现树形列表数据的处理的，因为这样可以实现无限层级的树形列表。在实际使用Pydantic和SqlAlchemy来直接处理嵌套关系的时候，总是出现数据在Pydantic的对象转换验证上，爬坑一段时间才发现是模型定义使用上的问题，本篇随笔介绍使用Pydantic和SqlAlchemy实现树形列表数据（自引用表关系）的处理，以及递归方式处理数据差异。

1、使用Pydantic和SqlAlchemy实现树形列表数据（自引用表关系）的处理

默认的机构表的sqlalchemy的模型定义如下所示。

class Ou(Base):
    """机构（部门）信息-表模型"""

    __tablename__ = "t_acl_ou"

    id = Column(Integer, primary_key=True, comment="主键", autoincrement=True)
    pid = Column(Integer, ForeignKey("t_acl_ou.id"), comment="父级机构ID")

   ****其他信息

    # 定义 parent 关系
    parent = relationship(
        "Ou", remote_side=[id], back_populates="children")

    # 定义 children 关系
    children = relationship("Ou", back_populates="parent")

然后对应的DTO（Schema）数据类定义如下。

class OuDto(BaseModel):
    id: Optional[int] = None
    pid: Optional[int] = None
    ***其他信息

class OuNodeDto(OuDto):
    """部门机构节点对象"""

    children: Optional[List["OuNodeDto"]] = None  # 这里使用 Optional

    class Config:
        orm_mode = True  # 启用 orm_mod
        from_attributes = True
        extra = "allow"

然后我在机构的Crud类里面定义了一个get_children的函数，如下所示

    async def get_children(self, db: AsyncSession, id: int) -> Ou:
        """
        获取子列表
        :param db:
        :param id:
        :return:
        """
        result = await db.execute(
            select(Ou).options(selectinload(Ou.children)).where(Ou.id == id)
        )
        result = result.scalar_one_or_none()
        return result

这里通过 selectinload 的加载方式，可以再数据检索的时候，同时获得子列表的处理。

为了验证数据能够再CRUD中正常的检索出来，我对CRUD类的接口进行测试，并查询获得其中的children集合，代码如下所示

async def test_list_ou():
    async with async_session() as db:
        ou = await ou_crud.get_children(db, "3")
        print(vars(ou))
        for o in ou.children:
            print(vars(o))

        await db.close()

其中机构id为3的，是广州分公司，它把该公司下属所有的机构都能正常读取出来，因此底层没有问题。 

但是利用FastAPI的接口处理，通过pydantic的数据转换就是不能正常获得，如下是FastAPI的路由接口实现。

@router.get(
    "/get-children",
    response_model=AjaxResponse[OuNodeDto | None],
    summary="根据名称获取客户",
    dependencies=[DependsJwtAuth],
)
async def get_children(
    id: Annotated[int | None, Query()] = None,
    db: AsyncSession = Depends(get_db),
):
    ou = await ou_crud.get_children(db, id)
    try:
        result = OuNodeDto.model_validate(ou)
    except Exception as e:
        print(e.json())
        return AjaxResponse(
            success=False, result=None, errorInfo=ErrorInfo(message=str(e))
        )
    return AjaxResponse(result)

这里注意，我使用 OuNodeDto.model_validate(ou) 对嵌套列表对象进行转换的，出错就是在这里。

具体我们可以再Swagger界面中调试获得错误信息。

我反复核对模型Model和Schema的对象都是一一对应的，错误不是字段名称的问题，因此可能是数据处理上的问题，但是很难从其中获得更多有用的信息。在Chatgpt中获得的错误提示如下所示。

为什么我的嵌套列表可以查询出来，而通过Schema的model_validate转换的时候，就提示validation errors？

你遇到的这个问题可能是因为 Pydantic 的模型验证过程中遇到了与嵌套数据结构相关的不一致性或问题。以下是一些常见的原因及其解决方法：

1）嵌套结构不匹配

确保你的嵌套数据结构与 Pydantic 模型定义一致。如果你的模型预期的是一个嵌套的列表，但数据库查询返回的结果中缺少某些字段或类型不匹配，可能会导致验证失败。

解决方法:
  • 检查从数据库查询出来的数据结构，确保它与 Pydantic 模型中的嵌套定义一致。

2）前向引用 (Forward References)

如果你的 Pydantic 模型有自引用或互相引用的情况，确保你正确使用了 update_forward_refs()。如果在嵌套引用中没有正确处理前向引用，可能会导致验证失败。

解决方法:

　　确保你在 Pydantic 模型定义之后调用了 update_forward_refs()，pydantic新版使用model_rebuild，特别是当模型包含递归引用时。

3）使用from_attributes 选项

如果你的数据来自 ORM 对象（或任何非字典的对象），而你使用的是 Pydantic v2，可以尝试使用 from_attributes 属性。

解决方法:

  • 在 Config 中启用 from_attributes 选项以确保 Pydantic 模型能够从属性中提取数据。

4） 数据库返回的数据类型问题

确保从数据库返回的数据类型（特别是 children 字段）是你预期的类型。如果 children 返回的不是一个列表或是一个包含子对象的对象，则会导致验证失败。

解决方法:

　　检查你的查询逻辑，确保 children 字段返回的是一个列表，并且列表中的每个项符合 OuNodeDto模型的要求。

5）未正确处理关系加载

在使用 SQLAlchemy 时，确保相关数据（如 children）已被正确加载。如果尝试访问未加载的关系，可能会抛出 StatementError。

result = await db.execute(
    select(Ou).options(selectinload(Ou.children)).where(Ou.id == id)
)

 

最后发现这些我都已经做了，我的pydantic模型定义如下所示，还是会出错。

class OuNodeDto(OuDto):
    """部门机构节点对象"""

    children: Optional[List["OuNodeDto"]] = None  # 这里使用 Optional

    class Config:
        orm_mode = True  # 启用 orm_mod
        from_attributes = True
        extra = "allow"


# 更新前向引用
OuNodeDto.model_rebuild(force=True)

如果记录返回的对象是正常的，但在使用 OuNodeDto.model_validate(ou) 转换时出现错误，可能的问题出在 Pydantic 模型的定义或对象结构与 Pydantic 模型预期的格式不完全匹配。

最后发现是 relationship 的 lazy 参数的加载策略的影响。

lazy 加载策略的概述

在 SQLAlchemy 中，relationship 的 lazy 参数决定了如何和何时加载相关的对象。常见的 lazy 加载策略有：

  1. lazy="immediate":

    • 定义：这种策略会在加载父对象时立即加载相关的子对象。即，父对象和它的子对象会在同一个查询中加载。
    • 为什么有效：因为 lazy="immediate" 会立即加载所有相关的对象，当你使用 Pydantic 的 model_validate 进行数据验证时，相关对象已经被加载并可供访问。

  2. lazy="select":

    • 定义：这种策略会在访问关系时通过单独的查询来加载相关对象。即，只有当你访问子对象时，SQLAlchemy 才会发起额外的查询来获取这些对象。
    • 为什么可能无效：由于子对象是在访问时才加载的，因此在你进行 model_validate 验证时，可能子对象还没有被加载，导致验证失败。

  3. lazy="dynamic":

    • 定义：这种策略返回一个查询对象而不是实际的子对象。你需要显式地执行这个查询来获取相关的子对象。
    • 为什么可能无效：lazy="dynamic" 返回的是查询对象而不是实际的对象实例。因此，Pydantic 的 model_validate 无法直接处理这些查询对象，必须先执行查询来获取实际的对象。

使用 lazy="immediate"

class Ou(Base):
    __tablename__ = "t_acl_ou"
    id = Column(Integer, primary_key=True)
    pid = Column(Integer, ForeignKey("t_acl_ou.id"))
    name = Column(String)
    parent = relationship("Ou", remote_side=[id], back_populates="children", lazy="immediate")
    children = relationship("Ou", back_populates="parent", lazy="immediate")

在这种情况下，当你查询一个 Ou 对象时，children 已经被立即加载，可以直接用于 Pydantic 的 model_validate。

使用 lazy="select"

class Ou(Base):
    __tablename__ = "t_acl_ou"
    id = Column(Integer, primary_key=True)
    pid = Column(Integer, ForeignKey("t_acl_ou.id"))
    name = Column(String)
    parent = relationship("Ou", remote_side=[id], back_populates="children", lazy="select")
    children = relationship("Ou", back_populates="parent", lazy="select")

在这种策略下，children 只有在访问时才会被加载，这可能导致在进行 model_validate 验证时 children 尚未加载完成。

使用 lazy="dynamic"

class Ou(Base):
    __tablename__ = "t_acl_ou"
    id = Column(Integer, primary_key=True)
    pid = Column(Integer, ForeignKey("t_acl_ou.id"))
    name = Column(String)
    parent = relationship("Ou", remote_side=[id], back_populates="children", lazy="dynamic")
    children = relationship("Ou", back_populates="parent", lazy="dynamic")

lazy="dynamic" 返回的是一个查询对象，而不是实际的 children 对象。为了使用 Pydantic 进行验证，你必须先执行这个查询来获取实际的对象。

lazy 加载策略总结

  • lazy="immediate": 立即加载相关对象，使其在 Pydantic 的 model_validate 中可用。
  • lazy="select": 需要在访问时加载相关对象，可能在验证时尚未加载。
  • lazy="dynamic": 返回查询对象，需要额外的查询步骤，model_validate 无法直接处理。

在 SQLAlchemy 中，lazy 模式是模型定义的一部分，决定了如何加载相关的对象。

为了确保 model_validate 正常工作，通常建议使用 lazy="immediate" 以确保所有相关数据在进行验证时已经被完全加载。

最后修改为lazy="immediate" 后，工作正常，顺利进行列表的转换了。

 

2、递归方式处理树形列表数据

为了确保 Pydantic 的 model_validate 能正确处理嵌套关系，推荐使用 lazy="immediate" 策略。这样可以保证在 Pydantic 进行数据验证时，所有相关数据已经完整加载。

除了这样对树形列表进行处理外，还有什么好办法处理？

处理树形列表（或树形结构）的常见方法包括以下几种，除了直接使用 SQLAlchemy 的 relationship 和 lazy="immediate" 加载策略外，还可以采用其他一些技术和工具来处理和操作树形数据结构。

下面介绍使用递归检索方式进行列表数据的处理。在 Python 中，递归处理树形列表的常见方法是使用递归函数遍历树结构。

假设你有一个部门（Ou）模型，每个部门可以有多个子部门（树形结构）。你想要使用递归方法遍历并填充树形结构中的每个节点。

通过 Pydantic 的 BaseModel 类进行遍历填充，可以结合递归和 Pydantic 的模型来处理树形结构的数据。以下是一个详细的示例，展示如何使用 Pydantic 的 BaseModel 类进行递归遍历和填充树形结构。

首先，定义一个 Pydantic 模型，用于表示树形结构中的节点。为了处理嵌套的子节点，可以在模型中使用递归类型注解。

from typing import List, Optional
from pydantic import BaseModel

class OuNodeDto(BaseModel):
    id: int
    name: str
    children: Optional[List['OuNodeDto']] = None  # 递归类型注解

    class Config:
        orm_mode = True

假设我们有一组嵌套的字典数据，表示树形结构：

ou_data = [
    {
        "id": 1,
        "name": "Root Department",
        "children": [
            {
                "id": 2,
                "name": "Child Department 1",
                "children": [
                    {"id": 4, "name": "Grandchild Department 1"},
                    {"id": 5, "name": "Grandchild Department 2"}
                ]
            },
            {"id": 3, "name": "Child Department 2"}
        ]
    }
]

通过 Pydantic 的 BaseModel，你可以直接进行递归填充。假设 ou_data 是从数据库或者其他外部来源获取的字典列表，你可以通过递归构造 OuNodeDto 实例。

def build_tree(data: List[dict]) -> List[OuNodeDto]:
    """
    递归遍历并构建 Pydantic 模型树。
    
    :param data: 包含树结构的字典列表
    :return: 填充后的 Pydantic 模型列表
    """
    tree = []
    for node_data in data:
        # 处理子节点递归填充
        children = build_tree(node_data.get("children", []))
        
        # 使用 Pydantic 的模型验证和创建对象
        node = OuNodeDto(
            id=node_data["id"],
            name=node_data["name"],
            children=children if children else None
        )
        tree.append(node)
    return tree

使用上面的 build_tree 函数，你可以递归地遍历数据，并使用 Pydantic 模型来构建整个树形结构。

ou_tree = build_tree(ou_data)

# 输出树形结构的Pydantic模型
for node in ou_tree:
    print(node)

运行上面的代码后，输出将是一个 Pydantic 模型的树形结构列表，已填充好所有数据。

OuNodeDto(id=1, name='Root Department', children=[
    OuNodeDto(id=2, name='Child Department 1', children=[
        OuNodeDto(id=4, name='Grandchild Department 1', children=None),
        OuNodeDto(id=5, name='Grandchild Department 2', children=None)
    ]),
    OuNodeDto(id=3, name='Child Department 2', children=None)
])

通过这种方式，你可以使用 Pydantic 的 BaseModel 结合递归函数来处理树形结构的数据填充和验证。Pydantic 提供了强大的数据验证和解析能力，使得处理复杂的嵌套结构变得更加容易。

 

如果是从数据库中检索获得的SqlAlchemy的模型类，应该如何递归遍历？

要从数据库中检索并递归遍历 SQLAlchemy 的模型类，然后将其转换为 Pydantic 的模型类，可以按照以下步骤进行操作。假设你已经定义了 SQLAlchemy 模型类和对应的 Pydantic 模型类，接下来将展示如何递归遍历和填充这些数据。

首先，我们定义一个包含自引用关系的 SQLAlchemy 模型。

from sqlalchemy import Column, Integer, String, ForeignKey
from sqlalchemy.orm import relationship, declarative_base

Base = declarative_base()

class Ou(Base):
    __tablename__ = "t_acl_ou"

    id = Column(Integer, primary_key=True, autoincrement=True)
    pid = Column(Integer, ForeignKey("t_acl_ou.id"))
    name = Column(String)

    # 自引用关系
    parent = relationship("Ou", remote_side=[id], back_populates="children")
    children = relationship("Ou", back_populates="parent")

然后定义一个对应的 Pydantic 模型，支持嵌套的子节点。

from typing import List, Optional
from pydantic import BaseModel

class OuNodeDto(BaseModel):
    id: int
    name: str
    children: Optional[List['OuNodeDto']] = None  # 递归类型注解

    class Config:
        orm_mode = True  # 允许从 ORM 对象转换

使用 SQLAlchemy 的查询从数据库中获取组织结构数据。为了处理嵌套的关系，你可以使用 selectinload 或其他类似的加载策略来预先加载子节点。

from sqlalchemy.future import select
from sqlalchemy.orm import selectinload, sessionmaker
from sqlalchemy.ext.asyncio import AsyncSession, create_async_engine

# 假设使用异步引擎
engine = create_async_engine('sqlite+aiosqlite:///./test.db')
Session = sessionmaker(engine, class_=AsyncSession, expire_on_commit=False)

async def get_ou_tree_by_id(ou_id: int):
    async with Session() as session:
        # 使用 selectinload 预先加载子节点
        result = await session.execute(
            select(Ou).options(selectinload(Ou.children)).filter_by(id=ou_id)
        )
        ou = result.scalars().first()
        return ou

编写一个递归函数，将 SQLAlchemy 的 ORM 对象转换为 Pydantic 模型对象。

def build_tree(node: Ou) -> OuNodeDto:
    """
    递归遍历 SQLAlchemy 模型，并转换为 Pydantic 模型。
    
    :param node: SQLAlchemy 模型实例
    :return: 填充后的 Pydantic 模型实例
    """
    # 使用 Pydantic 模型验证和创建对象
    node_dto = OuNodeDto(
        id=node.id,
        name=node.name,
        # 递归填充子节点
        children=[build_tree(child) for child in node.children] if node.children else None
    )
    return node_dto

结合以上步骤，从数据库中获取数据并构建树形结构。

import asyncio

async def main():
    # 获取指定 ID 的组织结构树
    ou = await get_ou_tree_by_id(1)
    
    # 递归构建树形结构的 Pydantic 模型
    ou_tree = build_tree(ou)
    
    # 输出树形结构
    print(ou_tree)

# 运行异步任务
asyncio.run(main())

执行上述代码后，ou_tree 将是一个包含组织结构树的 Pydantic 模型对象，所有嵌套的子节点将被递归地转换和填充。

 

使用 Pydantic 的 model_validate 处理并且relationship加载策略lazy=immediate 和通过递归SqlAlchemy的模型类填充，哪个性能更好？

在比较使用 Pydantic 的 model_validate 与通过递归手动填充 SQLAlchemy 模型类的性能时，主要考量点是数据加载策略和模型转换方式的效率。以下是两者的详细分析：

1） Pydantic 的 model_validate + lazy="immediate"

  • 工作原理:

    • 使用 lazy="immediate" 会在 SQLAlchemy 实例化对象时立即加载关联的子对象。这意味着在访问主对象时，子对象已经完全加载，不需要再发起额外的数据库查询。
    • 使用 Pydantic 的 model_validate 可以将 SQLAlchemy 的 ORM 对象直接转换为 Pydantic 模型。

  • 性能考虑:

    • 数据加载: lazy="immediate" 会在访问对象时自动加载相关数据，适合需要立即访问完整数据结构的场景，但它可能会导致不必要的加载，尤其是在不需要所有子对象的情况下。
    • 转换开销: model_validate 是一个单步操作，自动处理复杂嵌套对象的转换。虽然方便，但它的开销取决于对象的复杂性和嵌套深度。对于深度嵌套的大量对象，转换的时间可能较长。

  • 优点:

    • 简洁：减少了手动编写递归代码的需要。
    • 自动化：能够自动处理嵌套关系的转换。

  • 缺点:

    • 可能会导致不必要的数据加载。
    • 对于大规模嵌套对象，性能可能下降。

2）递归手动填充 SQLAlchemy 模型类

  • 工作原理:

    • 手动编写递归函数来遍历 SQLAlchemy 的 ORM 对象并转换为 Pydantic 模型。
    • 可以灵活地选择何时加载子对象（通过 selectinload, joinedload 等），从而在需要时再加载数据。

  • 性能考虑:

    • 数据加载: 手动控制数据加载策略，可以优化查询性能，避免不必要的数据加载。只在需要时加载数据，避免了 lazy="immediate" 带来的过度加载。
    • 转换开销: 手动递归通常只处理当前节点及其直接子节点，相对高效。你可以通过优化递归逻辑，减少不必要的对象创建和转换。

  • 优点:

    • 性能优化：可以根据需要优化加载策略和递归处理，避免不必要的计算和数据加载。
    • 灵活性：更灵活地控制对象的转换和数据访问。

  • 缺点:

    • 需要手动编写递归逻辑，增加了代码复杂性。
    • 不如 model_validate 自动化，容易出错。

3）总结与选择

  • 数据规模和复杂性较小时: model_validate + lazy="immediate" 更方便，且性能影响不大，可以快速实现自动化的 Pydantic 模型转换。

  • 数据规模大且嵌套深度较高时: 手动递归填充可能会更高效，尤其是在你需要精细控制数据加载策略时。这样可以避免过度加载，并且优化性能。

结论：如果你的应用场景对性能要求较高，并且数据结构较为复杂，手动递归可能更优。如果优先考虑代码的简洁性和开发效率，且数据规模不大，那么 model_validate 配合 lazy="immediate" 是更好的选择。

 

标签：lazy,SqlAlchemy,处理,id,ou,children,Pydantic,加载
From： https://www.cnblogs.com/wuhuacong/p/18384124

相关文章

  • 使用批处理对包含指定字符的文件进行批量重命名
    点击查看代码@echooffchcp65001rem使用批处理将文件夹下所有txt文件有11的字符重命名为22setlocalenabledelayedexpansion::遍历当前目录下的所有文件for%%Ain(*.txt)do(set"filename=%%~nxA"set"newfilename=!filename:11=22!"if"!filena......
  • Transformers: 引领自然语言处理的革命性工具
    transformers引言：Transformers的崛起在人工智能和自然语言处理(NLP)领域,Transformers模型的出现无疑是一场革命。而HuggingFace公司开发的Transformers库,更是将这场革命推向了一个新的高度。作为一个开源项目,Transformers为研究人员和开发者提供了一个强大而灵活的工具,使他......
  • Linux各个发行版防火墙处理
    CentOS防火墙处理：1、systemctlstatusfirewalld.service查看防火墙状态如果出现active（running），说明防火墙是开启的。2、systemctlstopfirewalld.service关闭防火墙3、systemctlstatusfirewalld.service再次查看防火墙状态如果出现disavtive（dead），说明防火墙已经关闭......
  • SQLServer数据库日志太大处理方式
    SQLServer数据库日志太大处理方式1.1 如下图，点击连接登陆数据库1.2 如下图，打开数据库属性窗口1.3 如下图，更改数据库恢复模式1.4 如下图，收缩数据库日志到这里已经完成了，数据库的日志收缩1.5 如下图，数据库恢复模式修改为完整至此，完成。......
  • 自然语言处理:第五十二章 LongCite：助力RAG应用，让大模型精准找到引用
    代码：https://github.com/THUDM/LongCite\数据：HF：https://huggingface.co/datasets/THUDM/LongCite-45k魔搭：https://modelscope.cn/datasets/AI-ModelScope/LongCite-45k模型：HF：https://huggingface.co/THUDM魔搭：https://modelscope.cn/organization/ZhipuAIDemo：https:/......
  • VU9P处理板设计原理图：412-基于单XCVU9P+双DSP C6678的双FMC接口 100G光纤传输加速计算
    基于单XCVU9P+双DSPC6678的双FMC接口100G光纤传输加速计算卡一、板卡概述板卡包括一片Xilinx FPGA  XCVU9P,两片 TI 多核DSP TMS320C6678及其控制管理芯片CFPGA.设计芯片满足工业级要求。FPGA VU9P 需要外接4路QSFP+(100Gbps)及其两个FMC HPC接口。DS......
  • 宝塔面板无法打开处理思路
    处理宝塔面板无法打开的问题时，可以按照以下步骤进行排查和解决：检查网络连接确认服务器网络是否正常。尝试访问其他网站或服务确认网络状态。确认宝塔面板端口默认情况下宝塔面板使用的是 8888 端口，确认是否有更改过端口号。检查防火墙设置，确保宝塔面板使用的端口已......
  • Python中的pool.map函数：高效处理数据与计算任务
    在Python中，map()函数是一个非常实用的工具，它能对序列（如列表、元组等）进行映射操作，将一个函数作用于序列中的每个元素，并将结果组成一个新的序列返回。在一些大规模的数据处理和计算任务中，我们往往需要对大量数据进行高效的处理。这时，map()函数就显得尤为重要，而它的一个实现——pool.......
  • 针对不同类型的数据，哪些Python可视化库更适合处理时间序列数据？
    关注我，持续分享逻辑思维&管理思维&面试题；可提供大厂面试辅导、及定制化求职/在职/管理/架构辅导；推荐专栏《10天学会使用asp.net编程AI大模型》，目前已完成所有内容。一顿烧烤不到的费用，让人能紧跟时代的浪潮。从普通网站，到公众号、小程序，再到AI大模型网站。干货满满。学成后可......
  • 2024年计算机视觉与图像处理国际学术会议 (CVIP 2024)
    2024年计算机视觉与图像处理国际学术会议(CVIP2024)2024InternationalConferenceonComputerVisionandImageProcessing(CVIP2024)2024年11月15-17日，杭州EI检索稳定！【重要信息】会议官网：iccvip.org大会时间：2024年11月15日-17日大会地点：中国杭州接受/拒稿......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99