CN117216026A

CN117216026A - Data migration method, migration message data display method, device and equipment

Info

Publication number: CN117216026A
Application number: CN202211503363.8A
Authority: CN
Inventors: 黄铁鸣; 韩承村; 吴晓珊; 冯泽荣; 李斌
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2022-11-28
Filing date: 2022-11-28
Publication date: 2023-12-12

Abstract

A data migration method, a migration message data display device and migration message data display equipment are provided. The data migration method comprises the following steps: obtaining migration message data to be migrated from a source database corresponding to a first enterprise to a target database corresponding to a second enterprise, wherein the migration message data is represented in the source database by a plurality of data tables, and the first enterprise and the second enterprise are both associated with the same user; inserting the first partial data table into a data table of the same type in a plurality of native data tables in the target database, wherein the plurality of native data tables are used for representing non-migration message data in the target database; and regenerating a second partial data table in the target database for the migration message data as a newly generated data table, wherein the migration message data is represented in the target database by the same type data table and the newly generated data table in the plurality of original data tables.

Description

Data migration method, migration message data display method, device and equipment

Technical Field

The present application relates to the field of internet technologies, and in particular, to a data migration method, a migration message data display device, a computer device, and a storage medium.

Background

Instant chat messaging services allow one user to message another user in real-time. Some instant messaging programs are now tailored to the business for administration, such as business version instant messaging programs and the like. If a user migrates from a first enterprise (e.g., a historic enterprise) to a second enterprise (e.g., a new enterprise), the user's account needs to be unbound to the first enterprise and bound to the second enterprise, so all chat data of the user account at the time of the first enterprise is not viewable after binding to the second enterprise as an important data resource.

However, contacts of the user account at the first business and contacts at the second business may overlap and the chat data is not an important data resource, and thus, the user may wish to have the chat data with the contacts be viewed when the account is bound to the second business and to ensure time continuity of the chat data, the chat data is displayed on the display interface before the chat data at the second business when the chat data at the first business is required to be displayed.

Accordingly, there is a need for a scheme that enables migration of chat data (also referred to as message data) of a user at a first enterprise as the user migrates from the first enterprise to a second enterprise, and orders the migration message data to be displayed before non-migration message data when the migration message data needs to be displayed.

Disclosure of Invention

According to an aspect of the present application, there is provided a data migration method, the method comprising: obtaining migration message data to be migrated from a source database corresponding to a first enterprise to a target database corresponding to a second enterprise, wherein the migration message data is represented in the source database by a plurality of data tables, and the first enterprise and the second enterprise are both associated with the same user; inserting a first portion of the plurality of data tables into a same type of data table of a plurality of native data tables in the target database, wherein the plurality of native data tables are used to represent non-migration message data in the target database; and regenerating a second part of the data tables in the target database for the migration message data as a newly generated data table, wherein the migration message data is represented in the target database by the same type of data table in which the first part of data table is inserted and the newly generated data table in the plurality of original data tables.

According to another aspect of the present application, there is provided a display method of migration message data, the method comprising: responding to the pulling triggering operation, and displaying a plurality of message data on a display interface; wherein, in the case where the plurality of message data includes migration message data and non-migration message data, the migration message data is displayed in front of the non-migration message data, wherein the migration message data is migrated from a source database corresponding to a first enterprise to a target database corresponding to the first enterprise, the non-migration message data is stored in the target database, and the first enterprise and the second enterprise are both associated with the user.

According to another aspect of the present application, there is provided a data migration apparatus, the apparatus comprising: an acquisition module, configured to acquire migration message data to be migrated from a source database corresponding to a first enterprise to a target database corresponding to a second enterprise, where the migration message data is represented in the source database by a plurality of data tables, and the first enterprise and the second enterprise are both associated with the same user; an inserting module, configured to insert a first part of data tables in the plurality of data tables into data tables of the same type in a plurality of native data tables in the target database, where the plurality of native data tables are used to represent non-migration message data in the target database; and a generating module, configured to regenerate, in the target database, a second partial data table of the plurality of data tables for the migration message data as a newly generated data table, where the migration message data is represented in the target database by the same type of data table as the first partial data table and the newly generated data table of the plurality of native data tables.

According to another aspect of the present application, there is provided a display apparatus for migrating message data, the apparatus comprising a display module which is operable to display a plurality of message data on a display interface in response to a pull trigger operation, wherein, in the case where the plurality of message data includes migrating message data and non-migrating message data, the migrating message data is displayed in front of the non-migrating message data, and wherein the migrating message data is migrated from a source database corresponding to a first enterprise to a target database corresponding to the first enterprise, the non-migrating message data is stored in the target database, and both the first enterprise and the second enterprise are associated with the user.

According to another aspect of the present application, there is provided a computer apparatus comprising: a processor; and a memory having stored thereon a computer executable program which, when executed by the processor, causes the processor to implement the steps of the method as described above.

According to another aspect of the present application there is provided a computer readable storage medium storing a computer executable program which when executed by a processor causes the processor to carry out the steps of the method as described above.

According to yet another aspect of the present application, there is also provided a computer program product comprising a computer executable program which, when executed by a processor, causes the processor to carry out the steps of the method as described above.

By inserting or regenerating each data table representing migration message data, the data migration method of the embodiment of the application has simple processing procedures of the data table, such as only entry insertion and data table replication in the data table, can include each data table representing migration message data in the target database, and distinguish partial data tables representing migration message data from corresponding types of data tables representing non-migration message data so as to facilitate message retrieval as will be mentioned later, thereby promoting update display of message data on a display interface. In addition, by determining the retrieval process for the message retrieval data table according to whether the determined reference message data is the migration message data and the different types of pull trigger operations, the technical effects of displaying the migration message data and then displaying the non-migration message data under the condition that the migration message data exists can be realized only by simple retrieval logic design and simple message retrieval mode without changing the display main logic. Furthermore, this approach is easily scalable, applicable to migration message data of different orders of magnitude, and maintenance costs are reduced when continued changes are required in the future.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for the description of the embodiments will be briefly described below, and it is apparent that the drawings in the following description are only some embodiments of the present application, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 is a schematic diagram of a network system that may implement a data migration method according to an embodiment of the present application.

FIG. 2 shows a flow diagram of a data migration method according to an embodiment of the present application.

FIG. 3 shows a flow diagram of a data migration method according to another embodiment of the present application.

Fig. 4 shows a schematic diagram of a process for retrieving message data and for updating an interface in the method as described in fig. 3.

Fig. 5 shows a schematic diagram of an instant messaging component.

Fig. 6 shows a flow diagram of the operation of the display process according to an embodiment of the present application.

Fig. 7 is a diagram illustrating an example of presenting migration message data on a display interface of an instant messaging application in accordance with an embodiment of the present application.

Fig. 8 shows a block diagram of a data migration apparatus according to an embodiment of the present application.

Fig. 9 shows a schematic block diagram of a computer device 900 in accordance with an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present application, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

First, the terms involved in the embodiments of the present application will be briefly described:

enterprise edition instant communication program client: the system is an instant messaging program client applied to office scenes, such as enterprise WeChat, nail or book flying client and the like, and is installed at a terminal. When a user migrates from a historical enterprise to a new enterprise, the account of the user at the client is unbound to the historical enterprise and bound to the new enterprise.

Database: a repository built on a computer storage device organizes, stores and manages data according to a data structure, rationally stores associated structured data sets, and a database contains various data tables, each data table being a set of associated row-wise data.

Data table: one of the most important components of a database, the data in a database is organized in data tables, a data table being a set of related row-wise data, e.g., a data table consisting of fields, keys, constraints, triggers, indices, statistics, etc. The data tables referred to in the present application are various tables for representing (e.g., organizing, storing, and managing) message data. These separate data tables are linked by relationships to form a cross-reference database.

Fig. 1 is a schematic diagram of a network system that may implement a data migration method according to an embodiment of the present application. The network system may include: a terminal 10, a server 20 and a network 30.

The terminal 10 may be an electronic device such as a cell phone, desktop computer, tablet computer, game console, electronic book reader, laptop portable computer, etc. The terminal 10 may have installed thereon a client of an application program, such as an enterprise edition instant messenger client, a social program client, a shopping program client, a game program client, a video program client, an audio program client, etc. The terminal 10 may run an application client that logs in using the user's account number, such as by cell phone number, mailbox number, user name, etc., in the terminal 10. The application client of the terminal may, at run-time, acquire data from the server 20 or a local storage device (e.g., a database on the local storage device) and present the acquired data on its display interface, and the data acquired at different times may be used to update the content displayed on the display interface. The terminal-related storage means may comprise a database. For example, at a terminal where an instant messenger client is installed, chat data generated by the instant messenger client when it is running may be stored in a local storage device (e.g., a database on the local storage device) of the terminal.

Server 20 is a background server of a client running on terminal 10 for providing background services to the client. The terminal may acquire local data from the local storage device in response to a data acquisition operation of the client (e.g., the client receives a refresh operation triggered by a user or receives a trigger operation of a refresh button by a user), or send a data acquisition request to the server 20 through the network 30 to acquire data generated at the server from the server 20.

The server 20 may be a server, a server cluster comprising a plurality of servers, or a cloud computing service center. The terminal and the server may be directly or indirectly connected through wired or wireless communication, and the present application is not limited herein.

As described above, if a user migrates from a history business to a new business, all chat data of the user at the time of the history business cannot be viewed after an account number is bound to the new business, and thus a scheme is required so that the chat data of the user at the time of the history business (hereinafter referred to as migration message data) can be migrated when the user migrates from the history business to the new business and displayed before the chat data of the new business (hereinafter referred to as non-migration message data) when displayed on a display interface.

As previously mentioned, chat data generated by the instant messenger client when running is stored in the local storage of the terminal (e.g., a database on the local storage), so that in the context of the present application, migration message data to be migrated from a first enterprise (historical enterprise) to a second enterprise (new enterprise) is actually message data stored in the local storage of the same terminal (e.g., a database on the local storage). The migration message data should also be message data for a common contact of the user at both enterprises.

According to the embodiment of the application, in order to enable the migration message data to be displayed before the message data of the new enterprise, a special value can be assigned to a certain field (for example, a ServerID) in a certain data table corresponding to each migration message data, and the field in the type data table corresponding to the non-migration message data of the new enterprise does not have a special value, so when a processor at the terminal performs message data sorting for display, the migration message data can be determined by judging the special value and displayed before the non-migration message data.

However, in this method, a special value is given to a field corresponding to the migration message data, and each terminal and the background alignment scheme are required, and since the representation of the field in the data table corresponding to the message data may be different for each terminal, the effect is large; in addition, the field may itself have a specific purpose, at which time the purpose for representing the migration message data is additionally increased, which is easily confused and unfavorable for future expansion.

According to another embodiment of the present application, in a manner similar to that described above, when migration is performed, a new special column may be added to a message_lookup table (for quickly retrieving messages) in a database storing message data (including migration message data and non-migration message data), whether each message data is migration message data is marked, and when a processor at a terminal performs message data sorting for display, the migration message data may be determined by judging each value of this special column and displayed before the non-migration message data.

However, for this way, two data table structures exist for the message data, two SQL sentences need to be maintained, and in the future, SQL needs to be changed, the leakage is easy to change, and the maintenance cost is high; the influence surface is large when the data table is modified, and all functions on a message retrieval data table related call chain in a database for storing message data are changed; in addition, the retrieval performance may be deteriorated, and the value corresponding to the newly added special column is a boolean (bol) value, but the sorting priority is highest (for sorting the migration message data before according to the value to be displayed before). That is, even if other columns in the data table correspond to indexes, the search may degrade into partial table scans (i.e., search only for a newly added special column).

Therefore, the embodiment of the application also provides a scheme for conveniently storing migration data information on the basis of not changing the storage and display logic of the original message, and displaying the message data (migration message data) corresponding to the historical enterprise first and then displaying the message data (non-migration message data) corresponding to the new enterprise when the migration message data and the non-migration message data need to be displayed.

FIG. 2 shows a flow diagram of a data migration method according to an embodiment of the present application. The method may be performed by an application client installed at a terminal as shown in fig. 1.

As shown in fig. 2, in step S210, migration message data to be migrated from a source database corresponding to a first enterprise to a target database corresponding to a second enterprise is acquired, wherein the migration message data is represented by a plurality of data tables in the source database, and the first enterprise and the second enterprise are both associated with the same user.

For example, when a user changes from a first enterprise (a historic enterprise) to a second enterprise (a new enterprise), certain message data needs to be migrated from a source database corresponding to the first enterprise to a target database corresponding to the second enterprise.

For example, the source database may store chat data (corresponding to migration message data mentioned later) generated by the user at the current terminal at the time of the first enterprise; the target database may store chat data (corresponding to non-migrant message data mentioned later) generated by the user at the current terminal at the time of the second enterprise. The source database and the target database each include a plurality of data tables.

Alternatively, the migration message data may include message data of a session of the user with contacts corresponding to the user at the first enterprise and the second enterprise, for example, the user is in contact with Zhang San at the first enterprise and still in contact with Zhang San at the second enterprise, so that chat data of the user with Zhang San at the first enterprise is the migration message data. There may be a plurality of such contacts whose respectively corresponding chat data may be distinguished by a session identification or session object identification in a particular data table.

As described above, these migration message data may be represented by a plurality of data tables, and message data stored in the source database may be managed by these data tables, or the like. For example, the plurality of data tables may include, but are not limited to, a session data table (conversion_table), an application information data table (message_appinfo), a file data table (file_table), a message search data table (message_lookup), and a cache data table (cache_mapping). Wherein the session data table may be used to represent information of session message data, such as content of session message data, time of session message data, session object, etc.; the application information data table may be used to represent reference relationships between messages for use in making reference message hops (e.g., reply messages); the file data table is used for representing files contained in the message data; the message retrieval data table is used for representing various attributes, identifications, storage addresses and the like of each message data (session message) so as to be used for quickly retrieving the message; and a cache data table for representing cache data and downloaded data (e.g., pictures, video, etc.). Of course, the migration message data may also be represented in other data table forms. In the present application, migrating migration message data from a source database to a target database may be considered as migrating content included in a plurality of data tables in the source database representing the migration message data to the target database (i.e., there is also a need for a corresponding data table in the target database to represent the migration message data).

In step S220, a first portion of the plurality of data tables is inserted into a same type of data table of a plurality of native data tables in the target database, wherein the plurality of native data tables are used to represent non-migration message data in the target database.

The non-migrant message data in the target database is message data that is originally stored in the target database (e.g., chat data generated when the user account is bound to the second enterprise). The types of the plurality of native data tables for representing the non-migration message data in the target database are the same as the types and formats of the plurality of data tables for representing the migration message data in the source database, and some types of data tables may be shared, in which case even if the migration message data is to be stored in the target database, only the corresponding entry needs to be added to the same type of native data table in the target database, i.e., part of the data tables in the plurality of data tables are inserted into the relevant (i.e., same type) native data tables in the target database corresponding to the second enterprise, thereby preventing redundant generation of new data tables and maintaining consistency of data processing.

Alternatively, the first partial data table may include a session data table, an application information data table, a file data table.

In step S230, a second partial data table of the plurality of data tables is regenerated in the target database for the migration message data as a newly generated data table.

In this way, the migration message data is represented in the target database by the same type of data table as the first partial data table and the new generation data table as described above inserted in the plurality of primary data tables.

Alternatively, the second partial data table may include identification information of the migration message data, for example, the identification information of the migration message data may be included by including a message retrieval data table. The message retrieval data table is associated with a message data retrieval process, e.g., the message retrieval data table may include information associated with each piece of message data, e.g., an identification of the message data, such that particular message data may be pulled from a target database (e.g., other data tables in the target database that include particular message data) based on the identification. In addition, the second partial data table may further include a cache data table. Although the cache data table may be inserted directly into the same type of data table as the native data table, it is preferably regenerated because of the relatively complex data formats (e.g., pictures, video, etc.) it contains.

For example, a FLAG bit FLAG of the data structure of each message data may be marked to indicate whether the corresponding message data is migration message data without changing the setting of a column in the data table, i.e., without changing the structure of the data table. New message retrieval and cache data tables may be generated for these migration message data (marked with flag bits), for example, the message retrieval and cache data tables associated with the migration message data in the source database are copied into the target database for subsequent message retrieval and data display.

In this way, the relevant information of the migration message data is already contained in the target database corresponding to the second enterprise, that is, a part of the data table has been inserted into the relevant native data table in the target database, and the remaining other part of the data table has been regenerated, so that when the message data displayed to the user needs to be pulled and updated in response to the user operation, the relevant information (for example, identification, index, storage address, etc.) of the migration message data can be obtained through retrieval of the data table (for example, message retrieval data table) in the target database, thereby pulling the corresponding message data from the target database.

By inserting or regenerating the respective data tables representing the migration message data according to the data migration method described with reference to fig. 2, the processing procedure of the data tables is relatively simple, for example, only the entry in the data table is inserted and the data table is copied, the respective data tables representing the migration message data can be contained in the target database to realize the storage of the migration message data, and the partial data tables representing the migration message data are distinguished from the corresponding type of data tables representing the non-migration message data, so as to facilitate the retrieval of the message as will be mentioned later, so as to promote the update display of the message data on the display interface.

According to the embodiment of the present application, based on the native data table (the partial data table in which the migration message data is inserted) and the new data table in the target database as described above, the display of the message data on the display interface can be facilitated, for example, when the migration message data and the non-migration message data need to be displayed, the migration message data is displayed before the non-migration message data.

Further, upon receiving a user session selection operation (which may be considered a first pull trigger operation) for a certain contact, the application client may perform a first data pull operation and pull a certain amount of message data (if any, e.g., an earlier predetermined amount of message data from a most recent piece of message data in time and may include migrated message data and/or non-migrated message data) for initial presentation of the display interface (e.g., message session area), the operation of specifically pulling data will be described later. Thereafter, other message data may be pulled to update the display interface in response to a subsequent pull trigger operation (e.g., a user up-slide operation, etc., a user down-slide operation, etc.) to present to the user the message data that the user corresponding to the current pull trigger operation desires to view.

Fig. 3 shows a flow diagram of a data migration method according to another embodiment of the present application, which mainly further includes a process of updating message data (e.g., in response to a pull trigger operation) displayed on a display interface.

As shown in fig. 3, steps S310 to 330 are identical to steps S210 to S230, and thus a description thereof will not be repeated here.

After the relevant information for the migration message data has been contained in the target database, the migration message data in the target database and the non-migration message data (native message data) in the target database may be stored in association with time (e.g., in chronological order) and represented by a data table. Message data (message data corresponding to a session that has been generated, and thus both migrated and non-migrated message data are possible) may be pulled according to a pull trigger operation, for example, according to a pull trigger operation from a user (e.g., a slide-up operation indicating that the user desires to view message data earlier in time than currently displayed message data (this application is referred to as previous message data) or a slide-down operation indicating that the user desires to view message data later in time than currently displayed message data (this application is referred to as subsequent message data). That is, if there is no pull trigger operation, no data pull is performed, so that no display update is performed on the display interface.

Thus, a data pull may be performed from the target database in response to each pull trigger operation for updating the display interface to present to the user the message data that the user desires to view.

For example, a batch (predetermined number) of message data may be pulled for display update for each pull trigger operation, and the pulled predetermined number of message data is displayed in chronological order. After this pull trigger operation, if there is a new pull trigger operation, a new pull process is required. For example, in an enterprise WeChat application, after a predetermined number of message data is pulled (and accordingly used to update the display interface) in response to a current pull trigger operation, if the user is still continuing to slide up, it is stated that the user also wants to continue to view more message data that is older than the currently displayed message data (the last pulled message data), so that the next batch of message data can continue to be pulled from the target database in response to the pull trigger operation that is slid up, and if the number of message data for the next batch that is pulled is less than the predetermined number (e.g., 20, but only 10 message data), the display interface can be updated with all (e.g., 10) message data that is pulled up. The operation when the pull trigger operation is a downward slide operation is also similar.

Accordingly, in response to each pull triggering operation, the message data for updating the display interface is retrieved from the respective data tables in the target database as described in step S340, and the message data for updating the display interface is pulled from the target database and displayed on the display interface based on the retrieval result as described in step S350.

For example, in step S340, specifically, one piece of message data, which is pulled from the target database in response to the last pull trigger operation and has the earliest time or the latest time, may be determined as reference message data based on the type of the current pull trigger operation, wherein the message data pulled in response to the first pull trigger operation includes at least one piece of message data which is retrieved from the second message retrieval data table or from the second message retrieval data table and the first message retrieval data table and has the latest time; and retrieving message data for updating the display interface from at least one of the first message retrieval data table and the second message retrieval data table according to whether the reference message data is the migration message data.

Optionally, the new generation data table includes a first message retrieval data table corresponding to the migration message data, and the plurality of native data tables includes a second message retrieval data table corresponding to the non-migration message data.

Optionally, the message data in the target database is stored according to time in the respective message retrieval data table, and if the message data which has not been previously pulled is received (for example, when a session selection operation of a user on a certain contact is received (which may be regarded as a first pulling trigger operation), a certain amount of message data (earlier message data from a piece of message data with the latest time) in the latest time may be pulled as the message data pulled for the first time, for example, since the time of non-migration message data in the target database may be earlier than the time of migration message data, the non-migration message data may be retrieved in the second message retrieval data table first, and pulled, and if the non-migration message data is not retrieved, or the amount of the retrieved non-migration message data is insufficient, the migration message data may be retrieved in the first message retrieval data table to obtain the message data pulled by the first pulling trigger operation; or if the last pull trigger operation has pulled message data, for example, from the second pull trigger operation, the earliest message data or the latest message in the last pulled message data may be obtained according to the type of the current pull trigger operation, for example, when the current pull trigger operation indicates that more previous message data is obtained (for example, an up-slide operation), the earliest message data pulled last may be obtained, and conversely, when the current pull trigger operation indicates that more subsequent message data is obtained (for example, a down-slide operation), the last message data is the latest (new) message data pulled last time as the reference message data. For example, the client at the terminal may determine the reference message data by determining the time of each piece of message data that was last pulled.

Then, one type of message data (migrated message data or non-migrated message data) may be retrieved from one of the first message retrieval data table and the second message retrieval data table according to whether the reference message data is the migrated message data, and if the number of the one type of message data retrieved is insufficient for the predetermined number corresponding to the batch, and it is determined that it is necessary to acquire the other type of message data (non-migrated message data or migrated message data) according to the indication of the current pull trigger operation, the other type of message data may be retrieved from the other one of the first message retrieval data table and the second message retrieval data table. As such, the message data for display on the display interface for display interface updating may include one or more pieces of migration message data, one or more pieces of non-migration message data, or both.

The following describes in detail how message data is retrieved for display on a display interface for display interface updating.

First, in the case where the reference message data is migration message data, the migration message data is retrieved from the first message retrieval data table, and then it is determined whether or not to retrieve non-migration message data from the second message retrieval data table, based on the size relationship of the number of the retrieved migration message data and the predetermined number.

For example, where the pull trigger operation indicates that more subsequent message data is pulled (e.g., a slide down operation), and where the number of retrieved migration message data is less than the predetermined number, it is determined to retrieve non-migration message data from the second message retrieval data table. The sum of the number of retrieved migration message data and the number of retrieved non-migration message data is less than or equal to the predetermined number, and the retrieved and accordingly pulled migration message data and non-migration message data are used as message data for display on a display interface for display interface update for a current pull trigger operation. In this case, the message data pulled this time includes both migrated message data and non-migrated message data (native message data of the target database).

Specifically, if the user performs a pull trigger operation (e.g., sliding down) that desires to view more subsequent message data to indicate that more subsequent message data is desired to be viewed after the time of the currently displayed message data, and the total number of migration message data is also less than the predetermined number of the number of messages of the batch of secondary pulls, i.e., the number of migration message data retrieved from the first message retrieval data table is less than the predetermined number, non-migration message data may be retrieved such that the number of migration message data and non-migration message data may be equal to the predetermined number, and thus in this case, non-migration message data may be retrieved from the second message retrieval data table. After the migration message data and the non-migration message data are retrieved, the retrieved migration message data and the retrieved non-migration message data may be pulled from the target database and used for display interface updates so that the user may view the subsequent message data. In some cases, the number of non-migrant message data retrieved from the second message retrieval data table may also be insufficient or the second message retrieval data table does not have non-migrant message data, i.e. the number of retrieved migrant message data and non-migrant message data may be equal to or less than the predetermined number. In this case, all migration message data is pulled.

In addition, the pulled migration message data is displayed before the non-migration message data according to the time of the message data.

For another example, if the current pull trigger operation indicates that more previous message data is pulled (e.g., a sliding-up operation), and the number of retrieved migration message data is sufficiently large, e.g., greater than or equal to a predetermined number, it is indicated that the batch of pulled message data may be all migration message data (at least a portion of all migration message data), so that the predetermined number of migration message data may be pulled and displayed chronologically on the display interface.

Thus, if the message data of the previous batch is only a part of all the migration message data, then in response to the current pull trigger operation (e.g., the up-slide operation), since the last message data of the previous batch is a migration data message, the above-described process may be repeated, i.e., continuing to retrieve earlier migration message data from the first message retrieval data table, and if the number of retrieved migration message data is less than the predetermined number, since the current pull trigger operation indicates that more previous message data is pulled, all the retrieved migration message data may be used as message data for updating the display interface for the current pull trigger operation. In this way, in the event that there is migration message data and the current pull trigger indicates that more previous message data is pulled, all of the migration message data may be retrieved in batches prior to retrieving non-migration message data in response to one or more pull trigger operations for corresponding updating of the display interface, and thus may be used to display the migration message data prior to displaying the non-migration message data upon display.

For another example, if the current pull trigger operation may indicate that more subsequent message data is pulled (e.g., a slide down operation), and the number of retrieved migration message data is sufficiently large, e.g., greater than or equal to a predetermined number, it may be stated that the batch of pulled message data may be all migration message data (at least a portion of all migration message data), and thus the predetermined number of migration message data may be pulled and displayed chronologically on the display interface. For example, the user may first operate to jump to migration message data earlier in time (e.g., by clicking on a top specific icon or by looking up to jump to selected specific chat data in an enterprise WeChat application) and then acquire migration message data later in time, i.e., slide down to acquire more subsequent migration message data. In this case, the message data pulled in response to the current pull trigger operation includes only the migration message data.

For another example, where the current pull trigger operation indicates that more previous message data is pulled and where the number of retrieved migration message data is less than the predetermined number, it is determined that non-migration message data is not to be retrieved from the second message retrieval data table and all of the retrieved migration message data is to be the message data for updating the display interface for the current pull trigger operation. In this case, the message data pulled this time includes only the migration message data.

Specifically, if the number of pieces of migration message data retrieved from the first message retrieval data table is smaller than the predetermined number (lot number), that is, the number of pieces of migration message data is insufficient for the predetermined number to be pulled by the lot, and if the user does not perform an operation desiring to acquire more subsequent message data at the same time, the subsequent message data may not be additionally acquired, that is, the second message retrieval data table is not retrieved, so that the retrieved migration message data is pulled directly from the target database and used for updating of the display interface.

In other cases, similarly, where the reference message data is not the migration message data, the non-migration message data is retrieved from the second message retrieval data table, and then it is determined whether to retrieve the migration message data from the first message retrieval data table based on the size relationship of the number of retrieved non-migration message data to the predetermined number.

For example, where a pull trigger operation indicates that more previous message data is pulled (e.g., a slide up operation), and where the number of non-migrated message data retrieved is less than the predetermined number, it is determined to retrieve the migrated message data from the first message retrieval data table. The sum of the number of retrieved non-migratory message data and the number of retrieved migratory message data is less than or equal to the predetermined number, and the retrieved non-migratory message data and the migratory message data are used as message data for a current pull trigger operation to be displayed on a display interface for display interface updating. In this case, the message data pulled this time includes both migrated message data and non-migrated message data (native message data of the target database).

Specifically, if the user performs a pull trigger operation that wants to view more previous message data, for example, slides up to indicate that more previous message data before the time of the currently displayed message data is desired to be viewed, and the number of non-migration message data retrieved from the second message retrieval data table is smaller than the predetermined number, that is, the number of non-migration message data is insufficient for the predetermined number of message numbers of the batch of secondary pulls, the migration message data may be retrieved so that the number of migration message data and non-migration message data may be equal to the predetermined number, and thus in this case, the migration message data may be retrieved from the first message retrieval data table. After the migration message data and the non-migration message data are retrieved, the retrieved migration message data and the retrieved non-migration message data may be pulled from the target database and used for display interface updating. In some cases, the number of migration message data retrieved from the first message retrieval data table may also be not large or the first message retrieval data table does not have migration message data, i.e. the number of retrieved migration message data and non-migration message data may be equal to the predetermined number or may be smaller than the predetermined number. In this case, all non-migrated message data is pulled.

For another example, if the current pull trigger operation indicates that more subsequent message data is pulled (e.g., a slide down operation), and the number of non-migrated message data retrieved is sufficiently large, e.g., greater than or equal to a predetermined number, it is indicated that the batch of pulled message data may be all non-migrated message data (at least a portion of all non-migrated message data), and thus the predetermined number of non-migrated message data may be pulled and displayed on the display interface in chronological order.

Thus, if the message data of the previous batch is only a part of all the non-migration message data, in response to the current pulling trigger operation, since the last message data of the previous batch is a non-migration data message, the above-described process may be repeated, i.e., the non-migration message data is continued to be retrieved from the second message retrieval data table, and if the number of retrieved non-migration message data is less than the predetermined number, since the current pulling trigger operation indicates that more subsequent message data is pulled, all the retrieved non-migration message data may be used as message data for updating the display interface for the current pulling trigger operation. In this way, non-migration message data can be retrieved in batches according to each pull trigger operation, so that the display interface can be updated.

For another example, if the current pull trigger operation indicates that more previous message data is pulled (e.g., a sliding up operation), and the number of non-migrated message data retrieved is sufficiently large, e.g., greater than or equal to a predetermined number, it is indicated that the batch of pulled message data may be all non-migrated message data (at least a portion of all non-migrated message data), so that the predetermined number of non-migrated message data may be pulled and displayed chronologically on the display interface. For example, the user may first jump to non-migration message data later in time and then acquire non-migration message data earlier in time, i.e., slide up to acquire more previous non-migration message data. In this case, the message data pulled in response to the current pull trigger operation includes only non-migrating message data.

For another example, when the current pull trigger operation indicates that more subsequent message data is pulled, and when the number of non-migrated message data retrieved is less than a predetermined number, it is determined that migrated message data is not retrieved from the first message retrieval data table, and all non-migrated message data retrieved is taken as message data for updating the display interface for the current pull trigger operation. In this case, the message data pulled this time includes only non-migration message data.

Specifically, if the number of non-migration message data retrieved from the second message retrieval data table is smaller than the predetermined number (batch number), that is, the number of migration message data is insufficient for the predetermined number to be pulled by the batch, and if the user does not perform an operation desiring to acquire previous message data at the same time, the previous message data may not be additionally acquired, that is, the first message retrieval data table is not retrieved, so that the retrieved non-migration message data is pulled directly from the target database and used for updating of the display interface.

To more clearly describe the scheme of displaying migration message data before non-migration message data shown in fig. 3, fig. 4 shows a process schematic of the method as described above.

As shown in fig. 4, reference message data (determined as described above) is first determined in process 1, and it is determined in process 2 whether the reference message data is migration message data, if the reference message data is migration message data, retrieval of the migration message data is performed in a first message retrieval data table (e.g., message retrieval data table) in process 3, and if the reference message data is not migration message data (i.e., is non-migration message data in a target database), retrieval of the non-migration message data is performed in a second message retrieval data table (e.g., message retrieval data table) in process 4.

Thereafter, if it is determined in process 5 that the migration message data retrieved in process 3 is insufficient (less than the predetermined number of messages for each batch of secondary pulls) and the current pull trigger operation indicates that more subsequent message data is pulled (e.g., a slide down operation), i.e., that the user desires to view more subsequent message data, then in process 6, a retrieval of non-migration message data may be performed in the second message retrieval data table; alternatively, if it is determined in process 5 that the migration message data retrieved in process 3 is sufficient (greater than or equal to the predetermined number of messages for each batch of secondary pulls) and/or that the current pull trigger operation does not indicate to pull more subsequent message data (not a sliding down operation), no additional retrieval is required.

On the other hand, if it is determined in process 7 that the non-migrated message data retrieved in process 4 is insufficient (less than the predetermined number of messages for each batch of secondary pulls) and the current pull trigger operation indicates that more previous message data is pulled (e.g., a slide-up operation), i.e., that the user desires to view more previous message data, then in process 8 the retrieval of the migrated message data may be performed in the first message retrieval data table; alternatively, if it is determined in process 7 that the non-migrated message data retrieved in process 4 is sufficient (greater than or equal to the predetermined number of messages for each batch of secondary pulls) and/or the current pull trigger operation does not indicate to pull more previous message data (not an up-slide operation), no additional retrieval is required.

In process 7, the message data to be pulled may be pulled from the target database for updating the message data displayed on the display interface based on the information associated with the message data retrieved in processes 3-8 (including migrated message data, non-migrated message data, or both).

It can be seen that in the schemes described with reference to fig. 3-4 that involve acquiring message data to be presented, by determining whether to perform message data retrieval in the second message retrieval data table or the first message retrieval data table of the target database based on whether the determined reference message data is the migration message data, and it can be further determined whether retrieval is also required to be performed in one of the second message retrieval data table and the first message retrieval data table that has not been previously retrieved, based on the number of the preliminarily retrieved message data and a different type of pull trigger operation, to retrieve the message data for display update. It can be seen that by means of a simple search logic design, and based on a simple message search mode (i.e. based on searching a message data search table, only related search functions need to be modified) and without changing display main logic (the display main logic will be described later), the technical effects of displaying the migration message data and then displaying the non-migration message data can be achieved under the condition that the migration message data exists. Furthermore, this approach is easily scalable, applicable to migration message data of different orders of magnitude, and maintenance costs are reduced when continued changes are required in the future.

Fig. 5 shows a schematic diagram of an instant message (instant message) component, and fig. 6 shows a flow diagram of the operation of a display process according to an embodiment of the present application, wherein a general flow involving pulling existing historical message data (including migrated message data and non-migrated message data as described above) and displaying on a display interface to effect an update to a current display interface is involved.

An application program is installed at the terminal to be displayed with the message data, such as an instant messaging application program (e.g., an enterprise micro message) installed according to an installation package transmitted from the server, and the instant messaging application program includes an instant message (instamessage) component for displaying a session message area in which the pulled message data is displayed as described above.

An instant message (instant message) component contains complete business session logic and may include 4 User Interface (UI) management components and 2 data management components, the structure of which may be as shown in fig. 5.

An instant Messaging (InstantMessaging) component is shown in FIG. 5, wherein InstantMessaging is an integrated management framework for instant Messaging components, four UI management components are used to manage layout and presentation of UI interfaces, and include a header information management (IMChatHeadView) component, a message content management (IMChatContentView) component, an input frame management (IMChatSendMessaging View) component, a sidebar information (bulletin, member list, secondary screen, etc.) management (IMChatTooInfoViewController) component. The two data management components may include a session data management (IMChatManager) component and an unread data management (imchatunreadmeasagemanager), both of which may also be considered as one component. These components all perform the corresponding operations under the management of the integrated management framework instantmessage.

The pulling, displaying and interaction with the user of session-related message data involved in embodiments of the present application is managed cooperatively by these components. The whole process can be summarized into an initialization stage, a data pulling stage and an interface updating stage.

In fig. 6, a flow diagram of the integrated management framework InstantMessaging control related component described above performing message pulling and interface updating is shown. The Logic and IMChatManager components shown can be integrated together or arranged separately, the Logic can be regarded as background Logic, and the Logic can be used for interaction and communication between a client of a terminal and the background; the other ui includes a header information management (IMChatHeadView) component, an input box management (IMChatSendMessageView) component, and a sidebar information (bulletin, member list, secondary screen, etc.) management (IMChatRoomInfoViewController) component.

Specifically, first, the integrated management framework instantmessage controls the IMChatManager component to perform session initialization, such as initializing an ID and a scene of a session, etc., and then the session data management (IMChatManager) component may keep listening (listen) to notification of session related network messages from the corresponding logical Logic, thereby completing initialization through callback (callback).

The integrated management framework instantmessage may then control the session data management (IMChatManager) component to pull message data from the corresponding logic, e.g., the message data pulled may be message data retrieved or pulled according to the methods described above with reference to fig. 2-4, which may be pulled from a database in a storage local to the terminal for display at a display interface at the terminal device based on subsequent processes. At this point, the integrated management framework InstantMessaging may update the interface states of the header information management (IMChatHeadView) component, the input frame management (IMChatSendMessageView) component, and the sidebar information (bulletin, member list, secondary screen, etc.) management (IMChatChaoomInfoViewController) component, which may then undergo display processing to complete the presented UI state update.

Thus, after the session data management (IMChatManager) component acquires the message data, since the session data management (IMChatManager) component caches the whole message object, after acquiring the message data, that is, when a message change event occurs, the buffer status of the session data management (IMChatManager) component needs to be updated, that is, the session data management (IMChatManager) component acquires the pulled message data from the logic corresponding to the session data management (IMChatManager) component, updates the message buffer, and notifies the integrated management framework (callback) of the processing timing when the integrated management framework (instMessaging) can process different message callbacks, and can update the interface status of the message content management (imchatcontView) component, for example, to present the pulled message data on the interface, and then the UI component performs display processing to complete the presented UI status update.

Optionally, the operations of the interface update phase may further include an interface update when a subsequent new message is generated, similar to the processing procedure of the pulled message data described above, for example, if the message data is newly generated (and the session data management (imchattmanager) component listens from the background logic), the session data management (imchattmanager) component obtains the newly generated message data from its corresponding logic and updates the message cache, and notifies the integrated management framework instmessaging through a callback (callback), and then the integrated management framework instancessaging may control the message content management (imchattontview) component to insert the message into the display interface, and may update the status of the unread message or the like.

That is, after the currently pulled message data is determined according to the method described with reference to FIGS. 2-4, the display of the message data on the display interface for display interface updates may be implemented based on the display processing scheme described with reference to FIGS. 5-6 (particularly, steps 4-7).

According to another aspect of the application, corresponding to the previous data migration method, a migration message data display method is also disclosed. Likewise, migration message data is migrated from a source database corresponding to a first enterprise to a target database corresponding to a second enterprise, the non-migration message data is stored in the target database (e.g., represented by a plurality of native data tables), and the first enterprise and the second enterprise are both associated with the user.

The display method may include: and responding to the pulling triggering operation of the user, displaying a plurality of message data on a display interface, wherein in the case that the message data simultaneously comprise the migration message data and the non-migration message data, the migration message data is displayed in front of the non-migration message data.

Similarly, the non-migrated message data is message data that exists natively in the target database, e.g., chat data of the user at the second enterprise.

Optionally, the migration message data and the non-migration message data are displayed differently on the display interface, e.g., a first display area displaying the migration message data and a second display area displaying the non-migration message data differ in background color, a split line exists between the first display area and the second display area, and/or a first font for displaying the migration message data and a second font for displaying the non-migration message data differ (e.g., a color, a font model, etc.) and/or the like.

As shown in fig. 7, for a contact C that exists when the user is at both the first enterprise and the second enterprise, the message data (i.e., the migration message data) of the user and C when the user is at the first enterprise may be displayed on the display interface, while further message data (i.e., the non-migration message data) of the user and C when the user is at the second enterprise is also displayed.

It can be seen that the migration data message is displayed before the non-migration message data so as to be continuous in time.

In addition, by reasonably setting the interface display mode of each UI component, a dividing line can be added between the migration message data and the non-migration message data, or different background colors, different font colors and the like can be distinguished. For example, in fig. 7, a row of text "more than the message data of C at the time of the first business" is added on the display interface between the migrated message data and the non-migrated message data.

In this way, by the migration message data display method, migration message data can be displayed before non-migration message data, so that a user can intuitively see message data of a first enterprise (history enterprise) and a second enterprise (new enterprise) ordered according to time sequence.

According to another aspect of the application, a data migration apparatus is also disclosed.

Fig. 8 shows a block diagram of a data migration apparatus according to an embodiment of the present application. The device may be located at a terminal as shown in fig. 1.

As shown in fig. 8, the data migration apparatus includes an acquisition module 810, an insertion module 820, and a generation module 830.

The obtaining module 810 may be configured to obtain migration message data to be migrated from a source database corresponding to a first enterprise to a target database corresponding to a second enterprise, where the migration message data is represented in the source database by a plurality of data tables, and the first enterprise and the second enterprise are each associated with a same user.

The insertion module 820 may be configured to insert a first portion of the plurality of data tables into a same type of data table of a plurality of native data tables in the target database, wherein the plurality of native data tables are configured to represent non-migrant message data in the target database.

The generating module 830 may be configured to regenerate, in the target database, a second partial data table of the plurality of data tables as a newly generated data table, where the migration message data is represented in the target database by the same type of data table of the plurality of native data tables as the first partial data table inserted and the newly generated data table.

As described above, based on such a data migration apparatus 800, by inserting or regenerating each data table representing migration message data, the processing procedure of the data table is simple, for example, only entry insertion in the data table and data table duplication, the relevant information of the migration message data can be contained in the target database, and the partial data table of the migration message data and the corresponding type of data table of the non-migration message data can be distinguished so as to facilitate message data retrieval for different data as will be mentioned later, to facilitate updated display of the message data on the display interface.

Optionally, the apparatus may further include a display data retrieval module 840 and a display module 850.

The retrieval module 840 may be configured to retrieve message data for updating the display interface from respective data tables in the target database in response to each pull trigger operation; and the display module 850 may be configured to pull the message data for updating the display interface from the target database based on the search result in response to each pull trigger operation and display the message data on the display interface, such that the message data for display on the display interface includes one or more pieces of migration message data, one or more pieces of non-migration message data, or both.

For example, the new data table may include a first message retrieval data table and the plurality of native data tables may include a second message retrieval data table, and the retrieval module 840 may be specifically configured to, upon display of the message data: determining, as reference message data, one of the earliest or latest message data pulled from the target database in response to the last pull trigger operation based on the type of the current pull trigger operation, wherein the message data pulled in response to the first pull trigger operation includes at least one of the most recent message data retrieved from the second message retrieval data table or from the second message retrieval data table and the first message retrieval data table; and retrieving message data for updating the display interface from at least one of the first message retrieval data table and the second message retrieval data table according to whether the reference message data is migration message data.

Further details of how the number of messages is retrieved from the first message retrieval data table and the second message retrieval data table are described in detail above with reference to fig. 2-4 and will not be repeated here.

According to another aspect of the present application, a display device for migrating message data is also correspondingly disclosed, and for example, the display device may be located at the terminal shown in fig. 1.

The display device for migration message data according to the embodiment of the present application may include a display module, which may display a plurality of message data on a display interface in response to a pull trigger operation, wherein in a case where the plurality of message data includes migration message data and non-migration message data, the migration message data is displayed in front of the non-migration message data, and wherein the migration message data is migrated from a source database corresponding to a first enterprise to a target database corresponding to the first enterprise, the non-migration message data is stored in the target database, and both the first enterprise and the second enterprise are associated with the user.

It should be noted that while the above-described modules and sub-modules are shown or described above by way of example, it should be understood that the apparatus may also be divided in different ways, or may be divided into more or fewer modules, or each module may be divided into further more or fewer sub-modules, depending on the different functions. In some example embodiments, the module or sub-modules thereof may be implemented in electronic hardware (e.g., general purpose processor, DSP, ASIC, FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, etc.), computer software (e.g., may be stored in Random Access Memory (RAM), flash memory, read Only Memory (ROM), erasable Programmable ROM (EPROM), etc.), or a combination of both.

Fig. 9 shows a schematic block diagram of a computer device 900 in accordance with an embodiment of the present application. The computer device may be a terminal as shown in fig. 1.

As shown in fig. 9, the computer device 900 includes a memory and a processor, the memory having stored thereon a computer executable program that, when executed by the processor, causes the processor to implement the various operations described in the steps of any of the data migration method and the migration message data display method as previously described.

By way of example, computer device 900 may include one or more processors, one or more memories, a network interface, an input device, and a display screen connected by a system bus. The memory includes a nonvolatile storage medium and an internal memory. The non-volatile storage medium of the computer device stores an operating system, and may also store a computer executable program that, when executed by a processor, causes the processor to implement the various operations described in the steps of any of the data migration method and migration message data display method described previously. The internal memory may also have stored therein a computer executable program which, when executed by a processor, causes the processor to perform the various operations described in at least a portion of the steps of any of the data migration method and migration message data display method described above.

The processor may be an integrated circuit chip with signal processing capabilities. The processor may be a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like, and may be of the X84 architecture or ARM architecture.

The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. It should be noted that the memory of the methods described herein is intended to comprise, without being limited to, these and any other suitable types of memory.

The display screen of the computer equipment can be a liquid crystal display screen or an electronic ink display screen, the input device of the computer equipment can be a touch layer covered on the display screen, can also be a key, a track ball or a touch pad arranged on the terminal shell, and can also be an external keyboard, a touch pad or a mouse and the like.

The computer device may be a terminal as shown in fig. 1. Wherein the terminal may include, but is not limited to: smart phones, tablet computers, notebook computers, desktop computers, smart televisions, etc.; a wide variety of clients (APP) may be running within the terminal, such as multimedia play clients, social clients, browser clients, information flow clients, educational clients, and so forth.

According to another aspect of the present application, there is also provided a computer-readable storage medium storing a computer-executable program which, when executed by a processor, causes the processor to implement the steps of any one of the data migration method and the migration message data display method described above.

According to yet another aspect of the present application, there is also provided a computer program product comprising a computer executable program which when executed by a processor implements the steps of any one of the data migration method and migration message data display method as described above.

It is noted that the flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of methods and apparatus according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises at least one executable instruction for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The embodiments of the application as described in detail above are illustrative only and are not limiting. It will be appreciated by those skilled in the art that various modifications and combinations of the embodiments or features thereof can be made without departing from the principles and spirit of the application, and such modifications are intended to be within the scope of the application.

Claims

1. A method of data migration, comprising:

obtaining migration message data to be migrated from a source database corresponding to a first enterprise to a target database corresponding to a second enterprise, wherein the migration message data is represented in the source database by a plurality of data tables, and the first enterprise and the second enterprise are both associated with the same user;

inserting a first portion of the plurality of data tables into a same type of data table of a plurality of native data tables in the target database, wherein the plurality of native data tables are used to represent native message data in the target database that is non-migration message data;

regenerating a second partial data table of the plurality of data tables in the target database for the migration message data as a newly generated data table,

wherein the migration message data is represented in the target database with the same type of data table as the first partial data table inserted and the new generation data table of the plurality of native data tables.

2. The method of claim 1, further comprising: in response to each pull trigger operation,

retrieving message data from each data table in the target database for updating a display interface; and

pulling the message data for updating the display interface from the target database based on the search result, displaying the message data on the display interface,

wherein the message data for updating the display interface includes one or more pieces of migration message data, one or more pieces of non-migration message data, or both.

3. The method of claim 2, wherein the new generation data table comprises a first message retrieval data table and the plurality of native data tables comprises a second message retrieval data table,

wherein retrieving message data for updating a display interface from respective data tables of the target database comprises: in response to the current pull trigger operation,

determining, as reference message data, one of the earliest time or the latest time message data pulled from the target database in response to the last pull trigger operation based on the type of the current pull trigger operation, wherein the message data pulled in response to the first pull trigger operation includes at least one of the most recent time message data retrieved from the second message retrieval data table or from the second message retrieval data table and the first message retrieval data table;

And retrieving the message data for updating the display interface from at least one of the first message retrieval data table and the second message retrieval data table according to whether the reference message data is migration message data.

4. A method according to claim 3, wherein retrieving the message data for updating the display interface from at least one of the first message retrieval data table and the second message retrieval data table according to whether the reference message data is migration message data, comprises:

retrieving migration message data from the first message retrieval data table in case the reference message data is migration message data;

determining whether to retrieve non-migration message data from the second message retrieval data table according to the size relationship between the number of the retrieved migration message data and the predetermined number.

5. The method of claim 4, wherein determining whether to retrieve non-migration message data from the second message retrieval data table based on a size relationship of a number of retrieved migration message data to a predetermined number comprises:

determining to retrieve non-migrated message data from the second message retrieval data table if the current pull trigger operation indicates that more subsequent message data is pulled and if the number of retrieved migrated message data is less than the predetermined number,

Wherein the sum of the number of the retrieved migration message data and the number of the retrieved non-migration message data is less than or equal to the predetermined number, and the retrieved migration message data and the non-migration message data are used as the message data for updating the display interface.

6. The method of claim 4, wherein determining whether to retrieve non-migration message data from the second message retrieval data table based on a size relationship of a number of retrieved migration message data to a predetermined number comprises:

when the current pulling triggering operation indicates that more previous message data or more subsequent message data are pulled and the number of the retrieved migration message data is greater than or equal to a preset number, determining that non-migration message data are not retrieved from the second message retrieval data table, and taking the retrieved preset number of migration message data as the message data for updating a display interface; or alternatively

And in the case that the current pulling triggering operation indicates that more previous message data is pulled, and the number of the retrieved migration message data is smaller than the preset number, determining that non-migration message data is not retrieved from the second message retrieval data table, and taking all the retrieved migration message data as the message data for updating the display interface.

7. A method according to claim 3, wherein retrieving the message data for updating the display interface from at least one of the first message retrieval data table and the second message retrieval data table according to whether the reference message data is migration message data, comprises:

retrieving non-migrated message data from the second message retrieval data table in the event that the reference message data is not migrated message data; and

determining whether to retrieve the migration message data from the first message retrieval data table according to the size relationship between the number of the retrieved non-migration message data and the predetermined number.

8. The method of claim 7, wherein determining whether to retrieve migration message data from the first message retrieval data table based on a size relationship of a number of retrieved non-migration message data to a predetermined number comprises:

determining to retrieve the migration message data from the first message retrieval data table if the current pull trigger operation indicates that more historical message data is pulled and if the number of non-migration message data retrieved is less than the predetermined number,

9. The method of claim 7, wherein determining whether to retrieve migration message data from the first message retrieval data table based on a size relationship of a number of retrieved non-migration message data to a predetermined number comprises:

when the current pulling triggering operation indicates to pull more previous message data or indicates to pull more subsequent message data, and when the number of the retrieved non-migration message data is greater than or equal to a preset number, determining not to retrieve migration message data from the first message retrieval data table, and taking the retrieved preset number of non-migration message data as the message data for updating a display interface; or alternatively

And when the current pulling triggering operation indicates that more new message data is pulled, and the number of the retrieved non-migration message data is smaller than the preset number, determining that migration message data is not retrieved from the first message retrieval data table, and taking all the retrieved non-migration message data as the message data for updating the display interface.

10. The method of claim 2, wherein the first message retrieval data table and the second message retrieval data table include identification information for each piece of the migrated message data and each piece of the non-migrated message data, respectively,

And pulling the message data for updating the display interface from the target database based on the search result, wherein the message data comprises:

and pulling the message data for updating the display interface from the target database based on the identification information of the message data for updating the display interface retrieved from at least one of the first message retrieval data table and the second message retrieval data table.

11. A method of displaying migration message data, comprising:

responding to the pulling triggering operation, and displaying a plurality of message data on a display interface;

wherein, in the case that the plurality of message data includes migration message data and non-migration message data, the migration message data is displayed in front of the non-migration message data,

the migration message data is migrated from a source database corresponding to a first enterprise to a target database corresponding to the first enterprise, the non-migration message data is native message data stored in the target database, and the first enterprise and the second enterprise are both associated with the user.

12. The method of claim 11, wherein the migration message data and the non-migration message data are displayed differently on a display interface.

13. A data migration apparatus comprising:

the system comprises an acquisition module, a storage module and a storage module, wherein the acquisition module is used for acquiring migration message data migrated from a source database corresponding to a first enterprise to a target database corresponding to a second enterprise, the migration message data are represented by a plurality of data tables in the source database, and the first enterprise and the second enterprise are both associated with the same user;

an inserting module, configured to insert a first part of data tables in the plurality of data tables into a data table of a same type in a plurality of native data tables in the target database, where the plurality of native data tables are used to represent native message data in the target database that is non-migration message data;

a generation module for regenerating a second partial data table of the plurality of data tables for the migration message data in the target database as a newly generated data table,

14. The apparatus of claim 13, further comprising:

The retrieval module is used for responding to each pulling triggering operation and retrieving message data for updating a display interface from each data table in the target database; and

a display module for pulling the message data for updating the display interface from the target database based on the search result in response to each pulling trigger operation and displaying the message data on the display interface,

15. The apparatus of claim 14, wherein the new generation data table comprises a first message retrieval data table and the plurality of native data tables comprises a second message retrieval data table,

wherein, the retrieval module is configured to, when displaying message data: in response to the current data pull operation,

16. A computer device, comprising:

a processor; and

a memory having stored thereon a computer executable program which when executed by the processor causes the processor to perform the steps of the method according to any of claims 1-12.

17. A computer readable storage medium storing a computer executable program which when executed by a processor causes the processor to perform the steps of the method of any one of claims 1-12.