refactor: add file size and checksum fields

[Johnson-zs]

Added file size field kFileSize to both Content and OcrText namespaces
in field_names.h to support file size based searching.
Added checksum field kCheckSum specifically to OcrText namespace for
integrity verification of OCR processed files.

These changes enable:

1. File size based searching capability in the search engine
2. Checksum verification for OCR processed documents
3. Better indexing and filtering capabilities

Influence:

1. Test searching with file size conditions
2. Verify OCR document integrity checks with checksum field
3. Ensure backward compatibility with existing search queries

refactor: 添加文件大小和校验和字段

在field_names.h中向Content和OcrText命名空间添加了文件大小字段kFileSize
以支持基于文件大小的搜索。
向OcrText命名空间专门添加了校验和字段kCheckSum用于OCR处理文件的完整性
验证。

这些改动实现了：

1. 搜索引擎中对文件大小条件的搜索能力
2. 使用校验和验证OCR处理文档的完整性
3. 更好的索引和过滤能力

Influence:

1. 测试带文件大小条件的搜索功能
2. 使用校验和字段验证OCR文档完整性
3. 确保与现有搜索查询的向后兼容性

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Johnson-zs

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• debian/deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[deepin-ci-robot]

deepin pr auto review

你好！我是CodeGeeX。我已仔细审查了你提供的Git Diff内容。这次修改主要为 Content 和 OcrText 命名空间添加了与文件大小和校验和相关的常量字段。

以下是我从语法逻辑、代码质量、代码性能和代码安全四个维度提出的审查意见和改进建议：

1. 语法逻辑

• 审查意见：语法上没有错误，使用 constexpr const wchar_t 定义编译期常量是符合现代C++标准的做法，确保了类型安全和编译期优化。
• 潜在逻辑问题：我注意到 kFileSize 在 Content 和 OcrText 两个命名空间中都被添加了，而 kCheckSum 仅在 OcrText 中添加。请确认这是否符合业务逻辑？通常情况下，文件的 checksum（校验和）和 file_size（文件大小）是文件本身的固有属性，如果在全文索引和OCR索引中都需要记录文件大小，那么大概率也需要记录校验和。如果是遗漏，建议补全 Content 命名空间中的 kCheckSum。

2. 代码质量

• 审查意见：代码风格与现有代码保持了一致，命名清晰（使用了 k 前缀表示常量，驼峰命名法），这很好。
• 改进建议（DRY原则与重构）：从Diff上下文可以看出，Content 和 OcrText 命名空间中存在大量重复的字段定义（如 kIsHidden, kAncestorPaths, kBirthTime, kModifyTime 以及新增的 kFileSize）。随着字段增多，这种重复违反了 DRY (Don't Repeat Yourself) 原则，未来如果字段名发生变动，需要修改多处。
  重构方案：建议提取公共的字段到一个新的命名空间（如 Common 或 Base），然后在特定命名空间中仅保留特有的字段，或者通过引入/继承来复用。

  // 改进示例
  namespace LuceneFieldNames {
  namespace Common {
      constexpr const wchar_t kIsHidden[] = L"is_hidden";
      constexpr const wchar_t kAncestorPaths[] = L"ancestor_paths";
      constexpr const wchar_t kBirthTime[] = L"birth_time";
      constexpr const wchar_t kModifyTime[] = L"modify_time";
      constexpr const wchar_t kFileSize[] = L"file_size";
  } // namespace Common
  
  namespace Content {
      // Content 独有的字段
  } // namespace Content
  
  namespace OcrText {
      constexpr const wchar_t kCheckSum[] = L"checksum";
      // OcrText 独有的字段
  } // namespace OcrText
  } // namespace LuceneFieldNames

3. 代码性能

• 审查意见：性能方面没有负面影响。constexpr 保证了这些字符串常量在编译期就完成了初始化，不会产生运行时构造的开销。宽字符字符串（wchar_t）在内存中的占用会比窄字符大，但在常量场景下这是不可避免且可接受的（尤其是如果底层Lucene引擎依赖宽字符）。

4. 代码安全

• 审查意见：本次变更不涉及直接的内存操作或逻辑运算，因此没有明显的内存安全或逻辑安全漏洞。
• 业务安全建议：
  1. Checksum算法选择：虽然这里只是定义了字段名，但在后续使用 kCheckSum 存储和校验数据时，请确保选择安全的哈希算法（如 SHA-256 或更强）。如果是为了防止恶意篡改，避免使用 MD5 或 SHA-1 等已被证明存在碰撞漏洞的算法；如果仅用于去重或快速比较，则 CRC32/MD5 亦可。
  2. FileSize的溢出风险：在后续使用 kFileSize 对应的值时，请注意文件大小可能会超过 32 位整数的最大值（约 4GB），确保在赋值和传递时使用 uint64_t 或 qint64（如果是Qt框架）等 64 位整数类型，以防整数溢出导致的安全问题。

---

总结

代码本身没有硬性错误，可以合并。但强烈建议评估 Content 中是否也需要添加 kCheckSum，并在未来的迭代中考虑重构重复的命名空间字段以提升代码的可维护性。

[Johnson-zs]

/forcemerge

[deepin-bot]

This pr force merged! (status: blocked)