你的需求是否与问题相关？请描述。
在处理元素元数据时，可能存在一个不期望的副作用。在 unstructured/partition/common.py 中，_add_element_metadata 方法作为文件类型分区装饰器的 add_metadata_with_filetype 的一部分被调用。这个方法本意是向使用该元素生成的元数据(包括文件名和文件类型)添加额外的信息，但现有的元数据被合并到一个新创建的元数据对象中，而不是相反的方式。由于其结构，新的元数据字段很容易被遗忘，给开发人员带来调试挑战。
描述你希望的解决方案
所有在元素上创建的元数据字段应默认保留，而分区特定的元数据(文件类型、文件名等)仍应覆盖。
描述你考虑过的替代方案
可以通过显式地将其添加到在 _add_element_metadata 中创建的新 ElementMetadata 中来将元数据传递过去，尽管对于开发人员来说，这可能很难识别，因为它没有明确地记录下来。
附加上下文
这个问题出现在 #1268 中，当时向元素元数据添加了 parent_id 和 category_depth 字段。
6条答案
按热度按时间yks3o0rb1#
@scanny -对此你有什么想法吗？
sxpgvts32#
我同意。在我看来，我们应该逐步减少对这个"辅助"函数的使用，用直接在元数据上进行操作来替换它，然后如果我们找不到一个有说服力的用例，就将其消除。
我怀疑原始的用例是将
LayoutElement对象(来自推理)转换为Element对象。它可能仍然对此有用。但它很复杂，而且它所做的大部分事情都不适用于Element对象，例如它们没有 ".links" 属性。所以我倾向于尽可能地将其隔离，找到它的复杂性仍然相关的地方(如果有的话),然后将其放在离那个动作更近的地方。
我认为这样做是将推理和LayoutElements封装到一个更广泛的方向的一部分，这样工作就不会与
Element和ElementMetadata核心耦合。最终，推理只是另一种生成具有Element和工程师不需要理解或推理其工作原理的方式，以便有效地与不涉及推理的分区器上的元素和元数据一起工作。bxjv4tth3#
明白了，谢谢你的解释。这些情况是否会作为你脑海中"减少复杂性"重构的一部分发生，还是你会将其限制在参数范围内？无论哪种方式，似乎都应该将其保留在待办事项列表中。
smtd7mpg4#
它可以。在我的经验中，这些重构有点像 Pick-up Sticks 游戏，当做得好时。你希望保持 PR 较小，以便它们能够快速审查，并尽可能通过某种实际的、可触摸的改进来保持它们的动力。每个都是一个“粘性” :)
从没有依赖关系的开始是明智的，然后逐步移动到“粘性”的依赖关系已经被先前的步骤移除。我倾向于认为这个
add_element_metadata()部分处于中间位置。大致如下：@process_metadata()和@add_metadata_with_filetype()结合在一起，使得每个执行的步骤序列可以交错，以便于推理后处理。add_element_metadata()所以每次取得微小的进步，与那些通过这些局部化的重构轻松修复的 bug 并行进行，随着时间的推移持续下去，这是我所说的一般方法。绝对不是某种大爆炸方法。
t98cgbkg5#
@scanny - 你最近是否对这个问题进行了重构？我记得你提到了一些辅助函数的耦合。
fquxozlt6#
@MthwRobinson,它曾经在
partition_html()的主分区循环中使用过add_element_metadata(),但现在已经不再使用了。它仍然通过
@add_metadata_with_filetype()装饰器间接地被用于filename和url元数据项(一个或另一个)。这个装饰器被很多分区器使用，所以需要在另一个PR中专门关注一下，以移除对它的使用。https://github.com/Unstructured-IO/unstructured/blob/main/unstructured/file_utils/filetype.py#L601