一种补丁信息更新的方法及系统、介质、电子设备与流程

本发明涉及补丁投放技术领域，尤其涉及一种补丁信息更新的方法及系统、介质、电子设备。

背景技术：

补丁投放是指在发布端通过发布平台将补丁文件投放给客户端，例如，应用程序的补丁更新。在补丁投放之前，需要在发布平台首先对补丁文件的投放数据进行管理，例如，对补丁文件以及其投放对象的客户端设备标识进行管理。现有技术中将补丁文件与其投放数据高耦合设计，在进行投放信息更新时效率低。

技术实现要素：

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的补丁信息更新的方法及系统。

一方面，本申请通过本申请的一实施例提供如下技术方案：

一种补丁信息更新的方法，用于补丁发布平台，所述补丁发布平台中包括储存有n个补丁文件的数据库，所述n个补丁文件分别定义n个补丁类，所述补丁类中包括与该补丁类对应补丁文件的补丁基础信息；所述补丁平台中还包括与所述n个补丁类分别建立逻辑关联的n个投放数据表，其中，所述投放数据表通过所述补丁基础信息与所述补丁类建立逻辑关联；

所述方法包括：

获取补丁投放请求参数；其中，所述补丁投放请求参数中包括补丁基础参数以及目标设备标识集；

基于所述补丁基础参数，从所述n个补丁类中确定与所述补丁基础参数匹配的第一补丁类；其中，所述第一补丁类对应所述多个补丁文件中的第一补丁文件；

从与所述第一补丁类逻辑关联的第一投放数据表中获取已有的设备标识集；其中，所述投放数据表中包括已有的设备标识集，已有的设备标识集包括所述第一补丁文件已投放过客户端设备的设备标识；

从所述目标设备标识集中筛选出与所述已有的设备标识集中的设备标识相同的设备标识，获得更新设备标识集；

从所述目标设备标识集中筛选出与所述已有的设备标识集中的设备标识不相同的设备标识，获得插入设备标识集；

基于所述更新设备标识集和所述插入设备标识集，对所述第一投放数据表进行处理，获得处理后的第一投放数据表；

将所述处理后的第一投放数据表中的数据写入所述数据库，更新所述第一补丁文件的信息。

可选的，所述补丁基础信息包括应用程序的包名信息、应用程序的版本号和补丁的版本号，所述投放数据表中包括补丁编码；

所述投放数据表通过所述补丁基础信息与所述补丁文件建立逻辑关联的方法，具体包括：

所述应用程序的包名信息、应用程序的版本号和补丁的版本号，与所述补丁编码建立逻辑关联。

可选的，所述补丁类中还包括用于储存该补丁类对应补丁文件的补丁投放状态信息的冗余字段，所述第一补丁文件的补丁投放状态信息储存于第一补丁类中的第一冗余字段；

所述方法还包括：

基于所述第一冗余字段中的补丁投放状态信息，获得所述第一补丁文件的补丁投放状态信息。

可选的，所述补丁基础参数包括应用程序的包名信息参数、应用程序的版本号参数和补丁的版本号参数；

所述基于所述补丁基础参数，从所述n个补丁类中确定与所述补丁基础参数匹配的第一补丁类，具体包括：

基于所述应用程序的包名信息参数、应用程序的版本号参数和补丁的版本号参数，调用对象获取函数，获取一个目标补丁类；

判断所述目标补丁类是否为空；

若所述目标补丁类不为空，则从所述n个补丁类中确定与所述补丁基础参数匹配的第一补丁类。

可选的，所述投放数据表中包括设备标识信息字段和设备标识类型字段，其中，所述设备标识类型字段用于储存已有的设备标识类型，所述设备标识信息字段用于存储所述已有的设备标识集；

所述从与所述第一补丁类逻辑关联的第一投放数据表中获取已有的设备标识集，具体包括：

调用条件筛选函数，从所述第一投放数据表中筛选出所述已有的设备标识类型中的第一设备标识类型；

调用逻辑筛选函数，从所述第一投放数据表中筛选出所述第一设备标识类型所包括的已有的设备标识，获取已有的设备标识集。

可选的，所述投放数据表中还包括用于储存补丁基础信息的冗余字段，所述第一补丁文件的补丁基础信息储存于所述第一投放数据表中的第二冗余字段；

所述方法还包括：

基于所述第二冗余字段中储存的补丁基础信息，获得所述第一补丁文件的补丁基础信息。

可选的，所述基于所述更新设备标识集和所述插入设备标识集，对所述第一投放数据表进行处理，获得更新后的第一投放数据，具体包括：

将所述已有的设备标识集中与所述更新设备标识集中的设备标识相同的第一设备标识更新为投放状态；

将所述插入设备标识集中的第二设备标识插入所述已有的设备标识集，并将所述第二设备标识标识为投放状态。

另一方面，本申请通过本申请的另一实施例提供一种补丁信息更新的系统，用于补丁发布平台，所述补丁发布平台中包括储存有n个补丁文件的数据库，所述n个补丁文件分别定义n个补丁类，所述补丁类中包括与该补丁类对应补丁文件的补丁基础信息；所述补丁平台中还包括与所述n个补丁类分别建立逻辑关联的n个投放数据表，其中，所述投放数据表通过所述补丁基础信息与所述补丁类建立逻辑关联；

所述系统包括：

第一获取模块，用于获取补丁投放请求参数；其中，所述补丁投放请求参数中包括补丁基础参数以及目标设备标识集；

补丁确定模块，用于基于所述补丁基础参数，从所述n个补丁类中确定与所述补丁基础参数匹配的第一补丁类；其中，所述第一补丁类对应所述多个补丁文件中的第一补丁文件；

第二获取模块，用于从与所述第一补丁类逻辑关联的第一投放数据表中获取已有的设备标识集；其中，所述投放数据表中包括已有的设备标识集，已有的设备标识集包括所述第一补丁文件已投放过客户端设备的设备标识；

第一筛选模块，用于从所述目标设备标识集中筛选出与所述已有的设备标识集中的设备标识相同的设备标识，获得更新设备标识集；

第二筛选模块，用于从所述目标设备标识集中筛选出与所述已有的设备标识集中的设备标识不相同的设备标识，获得插入设备标识集；

数据处理模块，用于基于所述更新设备标识集和所述插入设备标识集，对所述第一投放数据表进行处理，获得处理后的第一投放数据表；

补丁更新模块，用于将所述处理后的第一投放数据表中的数据写入所述数据库，更新所述第一补丁文件的投放信息。

本发明公开了一种可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述方法的步骤。

本发明公开了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述方法的步骤。

本申请实施例中提供的一个或多个技术方案，至少具有如下技术效果或优点：

本发明的方法，用于补丁发布平台，对补丁投放信息进行高效更新，作为基础，在补丁发布平台中包括储存有n个补丁文件的数据库。为了提高了补丁投放信息动态更新的效率，本发明首先在数据结构上将补丁文件与投放信息数据进行分离设计，具体是将数据库中的n个补丁文件分别定义n个补丁类，所述补丁类中包括与该补丁类对应补丁文件的补丁基础信息；并在补丁平台中构建与所述n个补丁类分别建立逻辑关联的n个投放数据表，其具体的逻辑关联的方法是通过代码将所述投放数据表通过所述补丁基础信息与所述补丁类建立逻辑关联，形成投放数据表与补丁文件的弱关联，这样就降低补丁文件与投放信息数据的耦合度。因此，在此数据结构基础上，可以直接在投放数据表中进行整个投放策略的实现，然后将投放策略写入数据库，对于一次投放请求，只需要对数据库完成一次访问即可完成补丁投放信息的更新，可显著提高补丁投放数据管理的效率。基于上述数据结构，本发明方法的补丁信息更新的步骤包括：获取补丁投放请求参数；其中，所述补丁投放请求参数中包括补丁基础参数以及目标设备标识集；基于所述补丁基础参数，从所述n个补丁类中确定与所述补丁基础参数匹配的第一补丁类；其中，所述第一补丁类对应所述多个补丁文件中的第一补丁文件；从与所述第一补丁类逻辑关联的第一投放数据表中获取已有的设备标识集；其中，所述投放数据表中包括已有的设备标识集，已有的设备标识集包括所述第一补丁文件已投放过客户端设备的设备标识；从所述目标设备标识集中筛选出与所述已有的设备标识集中的设备标识相同的设备标识，获得更新设备标识集；从所述目标设备标识集中筛选出与所述已有的设备标识集中的设备标识不相同的设备标识，获得插入设备标识集；基于所述更新设备标识集和所述插入设备标识集，对所述第一投放数据表进行处理，获得处理后的第一投放数据表；将所述处理后的第一投放数据表中的数据写入所述数据库，更新所述第一补丁文件的信息。该更新步骤针对一次更新请求中的参数，仅在与补丁文件弱关联的投放数据表中即完成了设备标识投放状态的更新，最后经过一次对数据库的访问，即完成补丁信息更新，避免现有技术频繁的对数据库进行访问，显著提高了补丁投放信息动态更新的效率。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1是本发明一种实施例中的补丁信息更新的方法流程图；

图2是本发明一种实施例中的补丁信息更新的系统构架图。

具体实施方式

本申请实施例通过提供一种补丁信息更新的方法及系统、介质、电子设备，解决了现有的投放信息更新效率低的技术问题。

本申请实施例的技术方案为解决上述技术问题，总体思路如下：

一种补丁信息更新的方法，用于补丁发布平台，所述补丁发布平台中包括储存有n个补丁文件的数据库，所述n个补丁文件分别定义n个补丁类，所述补丁类中包括与该补丁类对应补丁文件的补丁基础信息；所述补丁平台中还包括与所述n个补丁类分别建立逻辑关联的n个投放数据表，其中，所述投放数据表通过所述补丁基础信息与所述补丁类建立逻辑关联；所述方法包括：获取补丁投放请求参数；其中，所述补丁投放请求参数中包括补丁基础参数以及目标设备标识集；基于所述补丁基础参数，从所述n个补丁类中确定与所述补丁基础参数匹配的第一补丁类；其中，所述第一补丁类对应所述多个补丁文件中的第一补丁文件；从与所述第一补丁类逻辑关联的第一投放数据表中获取已有的设备标识集；其中，所述投放数据表中包括已有的设备标识集，已有的设备标识集包括所述第一补丁文件已投放过客户端设备的设备标识；从所述目标设备标识集中筛选出与所述已有的设备标识集中的设备标识相同的设备标识，获得更新设备标识集；从所述目标设备标识集中筛选出与所述已有的设备标识集中的设备标识不相同的设备标识，获得插入设备标识集；基于所述更新设备标识集和所述插入设备标识集，对所述第一投放数据表进行处理，获得处理后的第一投放数据表；将所述处理后的第一投放数据表中的数据写入所述数据库，更新所述第一补丁文件的投放信息。

为了更好的理解上述技术方案，下面将结合说明书附图以及具体的实施方式对上述技术方案进行详细的说明。

首先说明，本文中出现的术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

对于应用程序（app）的补丁更新是一种常用的软件更新方法。其主要通过在补丁发布平台对补丁文件对客户端的投放状态进行维护，在客户端触发更新时，补丁文件从平台发送给客户端进行应用更新。因此，在发布平台中，需要根据投放请求参数对补丁文件的投放信息进行更新（例如，针对客户端的投放状态更新），例如，对补丁文件以及其投放对象的客户端设备标识进行管理。现有技术中，补丁文件与其投放信息高耦合设计，对补丁文件的投放信息的更新仅仅是针对数据库中的补丁文件进行投放变更，使得需要频繁的对数据库进行强关联的访问，补丁文件的投放信息更新效率低。

为此，本申请首先通过实施例一提供了一种补丁信息更新的方法，以具体说明如何克服上述问题。

实施例一

本实施提供了一种补丁信息更新的方法，用于补丁发布平台，所述补丁发布平台中包括储存有n个补丁文件的数据库，所述n个补丁文件分别定义n个补丁类，所述补丁类中包括与该补丁类对应补丁文件的补丁基础信息；所述补丁平台中还包括与所述n个补丁类分别建立逻辑关联的n个投放数据表，其中，所述投放数据表通过所述补丁基础信息与所述补丁类建立逻辑关联；

需要说明的是，将补丁文件（英文patch）与投放策略（即上述的投放数据表）进行分离设计，这样的设计的优点是补丁和投放解耦，能够实现补丁和投放策略的独立管理。现有技术在实现的时候通常会将补丁与投放信息设计在一起，极大的提高耦合程度，后续功能升级迭代会比较繁琐。

在具体实施过程中，通过将补丁文件定义为类（即上述的补丁类），并通过类中定义补丁基础信息，与投放数据表建立逻辑关联，具体通过代码进行关联。需要说明的是，这里通过代码级别实现的逻辑关联与数据库现有的通过外键关联不同，外键关联是一种强关联，在操作时需要同时维护两端的数据，而逻辑关联是弱关联，在操作时只需要维护一端数据。因此，针对补丁更新时在发布平台中只需要根据投放请求中的参数，对补丁针对客户端设备的投放信息进行更新，因此，并不需要保证数据库中补丁文件数据的实时性（因为补丁并不需要生成即发送给客户端，而是在发布平台做好投放准备，待客户端触发时，才进行发送），因此，本发明的方法分离的设计，且通过逻辑关联，只需要对投放数据表进行单方面的维护，最后写入数据库即可，即可在发布平台对补丁投放信息进行更新，做好投放准备，不需要去频繁维护数据库，这显著提高了补丁信息更新的效率。

需要说明的是，补丁类可以包括多种，以安卓系统为例，可以将补丁文件定义为androidhotpatch这一个类，即表示安卓热补丁类。举例来说，该类中描述了补丁的具体信息，相关描述信息如下所述：

/***主键*/privateintegerid;

/***app应用id*/privatestringappid;

/***包名信息*/privatestringpkgname;

/***app版本号*/privateintegerversioncode;

/***版本名称*/privatestringversionname;

/***patch版本号*/privateintegerpatchversioncode;

/***补丁描述信息*/privatestringpatchdesc;

/***did投放状态新*/privateintegerdidpublishstatus;

/***渠道channel投放状态*/privateintegerchannelpublishstatus;

/***全量投放状态*/privateintegerallpublishstatus;

/***文件url*/privatestringfileurl;

/***文件大小(b)*/privateintegerfilesize;

/***文件md5*/privatestringfilemd5;

/***操作人*/privatestringoperator;

/***创建时间*/privatelongcreatetime;

/***更新时间*/privatelongupdatetime。

其中，包括应用程序的包名信息pkgname、应用程序的版本号versioncode和补丁的版本号patchversioncode等补丁基础信息。在具体实施过程中，通过pkgname、versioncode和patchversioncode可唯一确定一个补丁版本信息。

作为一种可选的实施方式，所述补丁类中还包括用于储存该补丁类对应补丁文件的补丁投放状态信息的冗余字段，所述第一补丁文件的补丁投放状态信息储存于第一补丁类中的第一冗余字段。

具体的，上述类结构中，增加设计了didpublishstatus的第一冗余字段，用于存储对应补丁文件的补丁投放状态信息，这样在后续查找是否投放的时候能够通过didpublishstatus非常高效的获取投放状态信息。

此外，投放数据表可以包括多个用于存储投放信息的字段，但至少包括用于储存与补丁类建立逻辑关联的信息的字段以及用于储存客户端设备标识的字段。举例来说，投放数据表的信息描述如下：

/***自增id*/privateintegerid;

/***android_hot_patch*/privateintegerpatchid;

/***投放的id信息,与publish_type联合确定*/privatestringpublishid;

/***投放id的类型信息1:did*/privateintegerpublishtype;

/***投放状态0:未投放，1:投放*/privateintegerpublishstatus;

/***冗余:包名信息*/privatestringpkgname;

/***冗余:app版本号*/privateintegerversioncode;

/***冗余:patch版本号*/privateintegerpatchversioncode;

/***操作人*/privatestringoperator;

/***创建时间*/privatelongcreatetime;

/***更新时间*/privatelongupdatetime。

具体的，所述投放数据表中包括补丁编码patchid；所述应用程序的包名信息、应用程序的版本号和补丁的版本号，与所述补丁编码建立逻辑关联。使得n个补丁类与n个投放数据表建立逻辑关联。

具体的，所述投放数据表中包括设备标识信息字段publishid和设备标识类型字段publishtype，其中，所述设备标识类型字段用于储存已有的设备标识类型，所述设备标识信息字段用于存储所述已有的设备标识集。

其中，设备标识信息字段和设备标识类型字段储存的信息可共同确定设备标识信息，而由于publishtype的存在，可实现设备标识类型的动态扩展，即可储存不同类型下的设备标识，例如，设备id（简写did）、设备注册使用的手机号等所有能唯一标识客户端设备的标识。这使得本发明的数据结构适用于各种类型的设备标识，具有很好的拓展性。在具体实施时，publishtype为1的时候表示是did类型，此时publishid存储的数据就是具体的did数据信息。也可以对publishtype进行扩展处理，扩展不同类型，那么publishid中存储的就是publishtype所对应类型的具体数据信息。

在清楚了上述数据结构后，下面基于上述数据结构，对如何实现补丁信息更新进行详细说明。

参见图1，所述方法包括：

s101、获取补丁投放请求参数；其中，所述补丁投放请求参数中包括补丁基础参数以及目标设备标识集；

s102、基于所述补丁基础参数，从所述n个补丁类中确定与所述补丁基础参数匹配的第一补丁类；其中，所述第一补丁类对应所述多个补丁文件中的第一补丁文件；

s103、从与所述第一补丁类逻辑关联的第一投放数据表中获取已有的设备标识集；其中，所述投放数据表中包括已有的设备标识集，已有的设备标识集包括所述第一补丁文件已投放过客户端设备的设备标识；

s104、从所述目标设备标识集中筛选出与所述已有的设备标识集中的设备标识相同的设备标识，获得更新设备标识集；

s105、从所述目标设备标识集中筛选出与所述已有的设备标识集中的设备标识不相同的设备标识，获得插入设备标识集；

s106、基于所述更新设备标识集和所述插入设备标识集，对所述第一投放数据表进行处理，获得处理后的第一投放数据表；

s107、将所述处理后的第一投放数据表中的数据写入所述数据库，更新所述第一补丁文件的投放信息。

下面参照图1，对本实施中各步骤进行详细的解释说明。

首先，执行步骤s101，获取补丁投放请求参数；其中，所述补丁投放请求参数中包括补丁基础参数以及目标设备标识集。

在具体投放信息更新过程中，需要设计一个投放函数，对投放数据表进行维护，该投放函数的输入即为补丁投放请求中的参数。其中，所述补丁投放请求参数中包括补丁基础参数以及目标设备标识集。相应的，投放函数的输入设计时，设备标识的输入是一个列表形式，因此，可支持一次性投放多个目标设备，即补丁投放请求参数中可包括目标设备标识集。其中，一次性投放多个目标设备，实现批量处理，显著提高投放效率，

具体的，以did设备标识为例，投放函数具体的函数定义如下：

publicvoidpublisdid(didpublisreqdidpublishreq){}

该函数是一个public公开类型返回值为void的函数，其函数名称是publisdid，参数类型是didpublisreq，参数是didpublishreq。

其中，didpublisreq参数表示投放did所需要的必要参数条件，具体didpublishreq中的信息如下所述：

/***包名信息*/@notnull(message="pkgname不能为空")privatestringpkgname;

/***版本号*/@notnull(message="versioncode不能为空")privateintversioncode;

/***patch版本信息*/@notnull(message="patchversioncode不能为空")privateintpatchversioncode;

/***更新包版本信息*/@notnull(message="didlist不能为空")privatelist<string>didlist;

其中，didlist表示需要投放的did列表信息，由于是一个列表，因此可以支持一次性投放多个did设备。补丁基础信息包括应用程序的包名信息、应用程序的版本号和补丁的版本号。

在获取补丁投放请求参数后，作为投放函数的输入参数，输入投放函数后，投放函数具体的实现逻辑如下：

接下来，执行s102，基于所述补丁基础参数，从所述n个补丁类中确定与所述补丁基础参数匹配的第一补丁类；其中，所述第一补丁类对应所述多个补丁文件中的第一补丁文件。

需要说明的是，在本实施例中针对每个补丁文件（可以理解为一个补丁包），分别进行投放数据表的维护，可实现补丁文件投放信息的精准更新。

在具体实施过程中，由于可应用程序的包名信息、应用程序的版本号和补丁的版本号唯一确定一个补丁文件，因此，通过s101中获得的应用程序的包名信息、应用程序的版本号和补丁的版本号，从所述n个补丁类中确定与所述补丁基础参数匹配的第一补丁类。

作为一种可选的实施方式，所述基于所述补丁基础参数，从所述n个补丁类中确定与所述补丁基础参数匹配的第一补丁类，具体包括：

基于所述应用程序的包名信息参数、应用程序的版本号参数和补丁的版本号参数，调用对象获取函数，获取一个目标补丁类；

判断所述目标补丁类是否为空；

若所述目标补丁类不为空，则从所述n个补丁类中确定与所述补丁基础参数匹配的第一补丁类。

具体的，以did设备标识为例，可通过调用

fetchhotpatch(didpublishreq.getpkgname(),didpublishreq.getversioncode(),didpublishreq.getpatchversioncode())函数来获取到一个androidhotpatch类型的对象热补丁hotpatch（即目标补丁类），其中，fetchhotpatch函数中是通过pkgname和versioncode和patchversioncode这三个维度来唯一锁定一个补丁文件。在fetchhotpatch内部的获取方法是通过上述三个条件进行匹配，只有完全匹配上就返回一个androidhotpatch类型的对象hotpatch。

其中，fetchhotpatch即为一种对象获取函数，在本实施例中，fetchhotpatch表示一个获取热补丁的函数。

接下来判断hotpatch对象是否为空，如果为空，此时就需要抛出一个异常终止这个投放流程，具体的抛异常的方法是

thrownewvenusexception(fail_find_patch_info,fail_find_patch_info_msg)，其中fail_find_patch_info和fail_find_patch_info_msg是两个产量信息。

如果不为空，接下来，执行s103，从与所述第一补丁类逻辑关联的第一投放数据表中获取已有的设备标识集；其中，所述投放数据表中包括已有的设备标识集，已有的设备标识集包括所述第一补丁文件已投放过客户端设备的设备标识。

为了后续对设备标识进行高效处理，首先需要从第一投放数据表中获取已有的设备标识集。需要说明的是，这里的已有的设备标识集可能为空，也可以不为空。当设备标识集为空时，则表示第一补丁文件之前还没有投放过（可以理解为对第一投放数据表第一次进行操作），如果不为空，则表示第一补丁文件之前投放过，则按照本发明的方法，必定在第一投放数据表中储存有已有的设备标识集。

作为一种可选的实施方式，所述投放数据表中包括设备标识信息字段和设备标识类型字段，其中，所述设备标识类型字段用于储存已有的设备标识类型，所述设备标识信息字段用于存储所述已有的设备标识集；

则，所述从与所述第一补丁类逻辑关联的第一投放数据表中获取已有的设备标识集，具体包括：

调用条件筛选函数，从所述第一投放数据表中筛选出所述已有的设备标识类型中的第一设备标识类型；

调用逻辑筛选函数，从所述第一投放数据表中筛选出所述第一设备标识类型所包括的已有的设备标识，获取已有的设备标识集

具体的，同样以did设备标识为例，

首先构造一个

publishp2ppatchexamplepublishp2ppatchexample=newpublishp2ppatchexample()。其中，publishp2ppatchexample类型的对象publishp2ppatchexample。

然后调用

publishp2ppatchexample.createcriteria().andpkgnameequalto(pkgname).andversioncodeequalto(versioncode).andpatchversioncodeequalto(patchversioncode).andpublishtypeequalto(publishtype)方法来实现对publishp2ppatchexample对象的筛选条件进行设置，在设置筛选条件的时候做了versioncode和patchversioncode和publishtype这三个方面的条件匹配规则，publishtype是输入的设备标识类型，表示对某种类型的设备标识进行更新。最后通过调用

publishp2ppatchmapper.selectbyexample(publishp2ppatchexample)方法来实现逻辑筛选功能，筛选出一个list<publishp2ppatch>类型的数据publishp2ppatchlist。

其中，publishp2ppatchexample.createcriteria()

是条件筛选函数，publishp2ppatchmapper.selectbyexample(publishp2ppatchexample)是逻辑筛选函数。

publishp2ppatchlist即是第一投放数据表中已有的设备标识集，接下来，为了提高设备标识的维护效率，需要将publishp2ppatchlist里面的数据与s101中投放函数输入的设备标识列表中的设备标识进行合并处理。合并最终的目的是需要实现：第一投放数据列表中已有的投放的设备标识，后续只进行状态更新操作；对于设备标识列表中有但是第一投放数据列表中又没有的设备标识，进行插入操作。因此，需要对publishp2ppatchlist里面的数据进行拆分成两块。

需要说明的是，现有技术中，由于没有对投放信息与补丁文件分离设计，因此，也不可能高效的实现对设备标识的上述插入和更新操作，因为现有的方法必须对数据库进行维护，考虑到对数据库频繁访问的低效率，因此，不可能去做到本实施中对设备标识的高效更新和插入操作。

接下来，执行s104，从所述目标设备标识集中筛选出与所述已有的设备标识集中的设备标识相同的设备标识，获得更新设备标识集。

在具体实施过程中，同样以did设备标识为例，首先通过定义的解析出相同did设备的函数，用于筛选出更新设备标识集，具体的函数定义如下所述：

privatelist<publishp2ppatch>

getupdatepublishp2ppatchlist(didpublishreqdidpublishreq,

list<publishp2ppatch>publishp2ppatchlist)

上述函数的实现如下：

首先定义一个接收集合，具体的定义如下所述list<publishp2ppatch>updatep2ppatchlist=newarraylist<>();

然后通过

for(publishp2ppatchpublishp2ppatch:publishp2ppatchlist)方式来对publishp2ppatchlist参数进行轮询处理，然后再轮询内部通过for(stringdid:didpublishreq.getdidlist())方式来进行二级轮询处理，然后再一次进行匹配，具体是通过

if(did.equals(publishp2ppatch.getpublishid()))方式来进行匹配，如果匹配成功就通过调用updatep2ppatchlist.add(publishp2ppatch)方法将匹配好的对象存储到updatep2ppatchlist中，最后通过调用returnupdatep2ppatchlist将存储数据的集合进行返回处理。

接下来，执行s105，从所述目标设备标识集中筛选出与所述已有的设备标识集中的设备标识不相同的设备标识，获得插入设备标识集。

在具体实施过程中，同样以did设备标识为例，通过定义的函数：

list<publishp2ppatch>getinsertpublishp2ppatchlist(didpublishreqdidpublishreq,androidhotpatchhotpatch,

list<publishp2ppatch>publishp2ppatchlist)

通过list<publishp2ppatch>insertpublishp2ppatch=newarraylist<>()函数来定义一个接收集合insertpublishp2ppatch。

然后将参数中publishp2ppatchlist的对象进行转换成一个list<string>类型的对象，具体的转化过程如下所述:

list<string>dbdidlist=

publishp2ppatchlist.stream().map(publishp2ppatch::getpublishid).collect(collectors.tolist());

return!dbdidlist.contains(item);

collect(collectors.tolist());

上述过程中，主要是通过一个map操作来提取getpublishid函数中的与所述已有的设备标识集中的设备标识不相同的设备标识，然后再匹配出!dbdidlist.contains(item)函数，也就是dbdidlist不存在的数据，返回一个一级集合数据dbdidlist，然后再通过.collect(collectors.tolist());函数将改数据转换成一个list<string>insertdidlist数据信息。

接下来，对dbdidlist的数据构造成一个publishp2ppatch对象，具体是通过for(stringdid:insertdidlist)方式来进行轮询处理，然后对publishp2ppatch对象进行赋值操作，最后通过调用存储函数insertpublishp2ppatch.add(publishp2ppatch)将赋值好的数据存储到insertpublishp2ppatch中，然后再通过returninsertpublishp2ppatch将数据进行返回。

接下来，执行s106，基于所述更新设备标识集和所述插入设备标识集，对所述第一投放数据表进行处理，获得处理后的第一投放数据表。

通过s105，可以将得到一个用于更新的更新设备标识集updatepublishp2ppatch和用于插入的插入设备标识集insertpublishp2ppatch。

在具体实施过程中，所述基于所述更新设备标识集和所述插入设备标识集，对所述第一投放数据表进行处理，获得更新后的第一投放数据，具体包括：

将所述已有的设备标识集中与所述更新设备标识集中的设备标识相同的第一设备标识更新为投放状态；

将所述插入设备标识集中的第二设备标识插入所述已有的设备标识集，并将所述第二设备标识标识为投放状态。

需要说明的是，将所述已有的设备标识集中与所述更新设备标识集中的设备标识相同的第一设备标识更新为投放状态，则不需要重复的插入第一设备标识，而只需要将所述插入设备标识集中的第二设备标识插入所述已有的设备标识集，并将所述第二设备标识标识为投放状态，显著提高数据处理效率。

接下来，执行s107，将所述处理后的第一投放数据表中的数据写入所述数据库，更新所述第一补丁文件的投放信息。

将处理后的第一投放数据表中的数据对数据库中的第一补丁文件的投放信息进行更新，完成对于s101中投放请求的任务，使第一补丁文件对于投放请求中的目标设备标识集做好投放准备，一但目标设备标识集对应的目标客户端设备触发更新，则将第一补丁文件投放给目标客户端设备。

上述本申请实施例中的技术方案，至少具有如下的技术效果或优点：

本实施例的方法，用于补丁发布平台，对补丁投放信息进行高效更新，作为基础，在补丁发布平台中包括储存有n个补丁文件的数据库。为了提高了补丁投放信息动态更新的效率，本发明首先在数据结构上将补丁文件与投放信息数据进行分离设计，具体是将数据库中的n个补丁文件分别定义n个补丁类，所述补丁类中包括与该补丁类对应补丁文件的补丁基础信息；并在补丁平台中构建与所述n个补丁类分别建立逻辑关联的n个投放数据表，其具体的逻辑关联的方法是通过代码将所述投放数据表通过所述补丁基础信息与所述补丁类建立逻辑关联，形成投放数据表与补丁文件的弱关联，这样就降低补丁文件与投放信息数据的耦合度。因此，在此数据结构基础上，可以直接在投放数据表中进行整个投放策略的实现，然后将投放策略写入数据库，对于一次投放请求，只需要对数据库完成一次访问即可完成补丁投放信息的更新，可显著提高补丁投放数据管理的效率。基于上述数据结构，本发明方法的补丁信息更新的步骤包括：获取补丁投放请求参数；其中，所述补丁投放请求参数中包括补丁基础参数以及目标设备标识集；基于所述补丁基础参数，从所述n个补丁类中确定与所述补丁基础参数匹配的第一补丁类；其中，所述第一补丁类对应所述多个补丁文件中的第一补丁文件；从与所述第一补丁类逻辑关联的第一投放数据表中获取已有的设备标识集；其中，所述投放数据表中包括已有的设备标识集，已有的设备标识集包括所述第一补丁文件已投放过客户端设备的设备标识；从所述目标设备标识集中筛选出与所述已有的设备标识集中的设备标识相同的设备标识，获得更新设备标识集；从所述目标设备标识集中筛选出与所述已有的设备标识集中的设备标识不相同的设备标识，获得插入设备标识集；基于所述更新设备标识集和所述插入设备标识集，对所述第一投放数据表进行处理，获得处理后的第一投放数据表；将所述处理后的第一投放数据表中的数据写入所述数据库，更新所述第一补丁文件的信息。该更新步骤针对一次更新请求中的参数，仅在与补丁文件弱关联的投放数据表中即完成了设备标识投放状态的更新，最后经过一次对数据库的访问，即完成补丁信息更新，避免现有技术频繁的对数据库进行访问，显著提高了补丁投放信息动态更新的效率。

实施例二

基于与实施例一同样的发明构思，本实施例提供一种补丁信息更新的系统，用于补丁发布平台，所述补丁发布平台中包括储存有n个补丁文件的数据库，所述n个补丁文件分别定义n个补丁类，所述补丁类中包括与该补丁类对应补丁文件的补丁基础信息；所述补丁平台中还包括与所述n个补丁类分别建立逻辑关联的n个投放数据表，其中，所述投放数据表通过所述补丁基础信息与所述补丁类建立逻辑关联；

参见图2，所述系统包括：

第一获取模块，用于获取补丁投放请求参数；其中，所述补丁投放请求参数中包括补丁基础参数以及目标设备标识集；

补丁确定模块，用于基于所述补丁基础参数，从所述n个补丁类中确定与所述补丁基础参数匹配的第一补丁类；其中，所述第一补丁类对应所述多个补丁文件中的第一补丁文件；

第二获取模块，用于从与所述第一补丁类逻辑关联的第一投放数据表中获取已有的设备标识集；其中，所述投放数据表中包括已有的设备标识集，已有的设备标识集包括所述第一补丁文件已投放过客户端设备的设备标识；

第一筛选模块，用于从所述目标设备标识集中筛选出与所述已有的设备标识集中的设备标识相同的设备标识，获得更新设备标识集；

第二筛选模块，用于从所述目标设备标识集中筛选出与所述已有的设备标识集中的设备标识不相同的设备标识，获得插入设备标识集；

数据处理模块，用于基于所述更新设备标识集和所述插入设备标识集，对所述第一投放数据表进行处理，获得处理后的第一投放数据表；

补丁更新模块，用于将所述处理后的第一投放数据表中的数据写入所述数据库，更新所述第一补丁文件的投放信息。

由于本实施例所介绍的数据处理的系统为实现本申请实施例一种补丁信息更新的方法所采用的系统，故而基于本申请实施例一中所介绍的补丁信息更新的方法，本领域所属技术人员能够了解本实施例的系统的具体实施方式以及其各种变化形式，所以在此对于如何利用本中的系统实现实施例一中的方法不再详细介绍。只要本领域所属技术人员用于实现本申请实施例中补丁信息更新的方法所采用的系统，都属于本申请所欲保护的范围。

基于与前述实施例中同样的发明构思，本发明实施例还提供一种可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前文任一所述方法的步骤。

基于与前述实施例中同样的发明构思，本发明实施例还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现前文任一所述方法的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。