fix: clear update logs to prevent duplicate entries

[xionglinlin]

The previous implementation did not clear the security and system log containers before appending new log data. This caused duplicate log entries to accumulate when the update log data was refreshed, resulting in repeated display of update information each time the logs were processed. Added appropriate clearing mechanisms:

1. Clear m_securityLog before processing security log entries
2. Clear itemInfo's current version and detail infos before processing system item info
3. Add clearDetailInfos() method to UpdateItemInfo for consistent detail info management

Log: Fixed duplicate update log entries issue

Influence:

1. Test update log display after system updates
2. Verify that log entries do not duplicate when refreshing update information
3. Check that security update logs show correctly without repeated entries
4. Verify item info version and details are properly reset before new data is filled
5. Test multiple update cycles to ensure logs remain clean

fix: 修复更新日志重复问题

之前的实现没有在追加新的日志数据前清空安全日志和系统日志容器，导致每次处
理记录时，日志条目累加，更新信息重复显示。增加了相应的清理机制：

1. 处理安全日志条目前清空 m_securityLog
2. 处理系统项目信息前清空 itemInfo 的当前版本和详细信息
3. 在 UpdateItemInfo 中添加 clearDetailInfos() 方法确保详细信息一致性 管理

Log: 修复了更新日志重复显示的问题

Influence:

1. 测试系统更新后更新日志的显示情况
2. 验证刷新更新信息时日志条目不会重复
3. 检查安全更新日志是否正确显示，没有重复条目
4. 验证新数据填充前项目信息版本和详情正确重置
5. 测试多个更新周期确保日志保持清晰

PMS: BUG-362665
Change-Id: I2cbdf3016e3a35c0e805aa6008f5b4bf293f823b

[deepin-ci-robot]

deepin pr auto review

你好！我是CodeGeeX，你的智能编程助手。我已经仔细审查了你提供的Git Diff代码。这次修改主要是在UpdateItemInfo类中新增了clearDetailInfos()方法，并在UpdateLogHelper处理系统日志和安全日志时，增加了对UpdateItemInfo状态的清空操作，以防止数据残留。

整体来看，代码逻辑清晰，修改目的明确。不过，为了进一步提升代码的语法逻辑、代码质量、代码性能和代码安全性，我提出以下改进建议：

1. 语法与逻辑

问题：setCurrentVersion("") 与 clearDetailInfos() 的逻辑一致性
在 handleSystemItemInfo 中，你添加了 itemInfo->setCurrentVersion("") 和 itemInfo->clearDetailInfos()，但在 handleSecurityItemInfo 中只添加了 itemInfo->clearDetailInfos()。

• 疑问：安全日志更新时，不需要重置 currentVersion 吗？如果安全更新也涉及版本信息的修改，建议保持两者的重置逻辑一致。
• 建议：如果 currentVersion 仅与系统更新相关则无需修改；如果也相关，建议补全 itemInfo->setCurrentVersion("");。

问题：handleSecurity 中的 clear() 时机与性能损耗
在 handleSecurity 方法中，m_securityLog.clear() 被放置在 for 循环之前。这是正确的，但需要确认 m_securityLog 的类型。

• 分析：如果 m_securityLog 是 QList 或 QVector，clear() 会析构所有元素并释放内存；如果在循环中不断 append，可能会触发多次内存重新分配。
• 建议：如果 log.keys().size() 可预估，建议在 clear() 后调用 reserve(log.keys().size()) 来预分配内存，提升性能。

2. 代码质量

建议：为 clearDetailInfos() 提供日志追踪
原有的 setPackages 和 addDetailInfo 都使用了 qCDebug 输出日志，这非常有助于调试。新增的 clearDetailInfos() 作为一个改变内部状态的重要操作，同样建议添加日志。

修改前：

void UpdateItemInfo::clearDetailInfos()
{
    m_detailInfos.clear();
}

修改后：

void UpdateItemInfo::clearDetailInfos()
{
    qCDebug(logDccUpdatePlugin) << "Clearing detail infos for item:" << m_name;
    m_detailInfos.clear();
}

3. 代码性能

问题：handleSecurity 中的 log.keys().size() 和 log.keys() 存在隐式共享拷贝风险
在 handleSecurity 中：

qCDebug(logDccUpdatePlugin) << "Handling security log with" << log.keys().size() << "entries";
m_securityLog.clear();
for (const auto& key : log.keys()) {

• 分析：QJsonObject::keys() 返回的是一个 QStringList（值类型）。每次调用 log.keys() 都会触发一次深拷贝（除非Qt进行了优化，但在C++11下遍历临时对象仍需谨慎）。这里调用了两次 log.keys()，意味着可能产生了两次不必要的数据拷贝。
• 建议：使用常引用接收 keys()，或者利用迭代器直接遍历 QJsonObject。

优化后代码：

void UpdateLogHelper::handleSecurity(const QJsonObject &log)
{
    const QStringList keys = log.keys(); // 使用 const 引用或局部常量避免重复计算和拷贝
    qCDebug(logDccUpdatePlugin) << "Handling security log with" << keys.size() << "entries";
    m_securityLog.clear();
    // 如果能预估大小，可以 m_securityLog.reserve(keys.size());
    for (const auto& key : keys) {
        const auto& obj = log.value(key).toObject();
        if (obj.isEmpty())
            continue;
        // ...
    }
}

或者更高效地使用 QJsonObject 的原生迭代器：

void UpdateLogHelper::handleSecurity(const QJsonObject &log)
{
    qCDebug(logDccUpdatePlugin) << "Handling security log with" << log.size() << "entries";
    m_securityLog.clear();
    for (auto it = log.constBegin(); it != log.constEnd(); ++it) {
        const auto& obj = it.value().toObject();
        if (obj.isEmpty())
            continue;
        // 使用 it.key() 获取 key
    }
}

4. 代码安全

问题：空指针解引用风险
在 handleSystemItemInfo 和 handleSecurityItemInfo 中，传入的指针 itemInfo 没有进行空指针检查（虽然开头有 if (m_systemLog.empty()) return; 这样的业务逻辑拦截，但并不能保证 itemInfo 本身非空）。

• 分析：如果上层调用传入了一个 nullptr，itemInfo->clearDetailInfos() 将导致程序崩溃（Segmentation Fault）。
• 建议：在函数入口处增加指针有效性校验。

修改后代码（以 handleSystemItemInfo 为例）：

void UpdateLogHelper::handleSystemItemInfo(UpdateItemInfo *itemInfo) const
{
    if (!itemInfo) {
        qCWarning(logDccUpdatePlugin) << "handleSystemItemInfo: itemInfo is null";
        return;
    }

    if (m_systemLog.isEmpty()) {
        return;
    }

    itemInfo->setCurrentVersion("");
    itemInfo->clearDetailInfos();
    // ...
}

---

总结

你的代码修改很好地解决了数据未清空导致的残留Bug，方向完全正确。建议按照上述意见进行微调，重点关注**空指针防御（安全性）和QJsonObject::keys()的重复拷贝（性能）**问题，这会让你的代码更加健壮和高效。

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: mhduiy, xionglinlin

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