How to read the fields returned by the interface when checking duplicates by title during batch import
How to retry checking duplicates by title during batch import and how to read the fields returned by the interface? The order cannot be reversed: Before moving historical content into the site, use the 'Check if the document exists by title' feature of the content system to go through the account, decide which titles to submit and which to skip; After importing, review the returned results to decide whether to retry. AnQiCMS provides the document content import interface /api/import/archive, and checking duplicates by title and batch import are the two tasks handled by this interface.
Which two carriers does the import interface receive?
There are two commonly used carriers for batch import within the site: one is a ZIP compressed package, suitable for moving historical content with documents, attachments, and images in a package; the other is an Excel spreadsheet, suitable for the scenario where the document list has been organized into a structured table, making it convenient to check titles and columns one by one. The common point of the two carriers is that submission is just the first step, and it is also necessary to read back the results and record the differences; otherwise, failed entries will silently blend in.
Why check by title first before submitting?
Duplicate imports usually bring two types of troubles: one is document duplication, where the same topic is listed twice in the column, and readers see two different update times; the other is when a batch is retried after a failure, and the parts that have already succeeded are poured in again. The import interface supports querying whether a title already exists, and performing a duplicate check before submission can turn 'whether or not' into a prerequisite rather than a post-clearing item. When migrating across sites, the duplicate check results are included in the migration list, so that you can continue from the progress of the last time even if you break in the middle.
Which fields in the returned data should be logged
After a single API call, it is recommended to understand and log the following types of information:
| Return information | What does it answer? | Suggested action |
|---|---|---|
| Does the existence of the title exist in the query? | Does this title exist on the site? | If it exists, skip or update the process; if it does not exist, submit it again. |
| The situation of the entries accepted this time | Which entries entered the import queue? | Reconciliation with the number of submissions; the difference is treated as a partial failure. |
| Failed entries and reasons | Which entries failed and where are they stuck? | Only retry specific problem entries, do not resend the whole batch |
A rule: Do not read back the script log of the returned field of the interface, retrying will degrade to 'resend the whole batch again'. The interface document organizes the document list and details, category tags, image upload, comment, and other high-frequency capabilities. Relevant conventions for batch import can be found in the category of interface help. Checking the field conventions before calling can save half of the return work.
How to do idempotent operations for repeated import
The simplest implementation of idempotence is 'check before submission, record after submission': the query results, submission results, and retry times of each title are all in the list, when the script is interrupted and re-run, read the list first, and titles that have been marked as successful will not be submitted to the interface again. With the ability to check for duplicates by title, even if the entire batch is re-run, duplicate documents will not be generated.
Common questions
How do I choose between Excel and ZIP carriers?Answer: Use a compressed package when moving historical content in bulk, including the attachment structure; use a table when items need to be manually checked and the relationship between columns is complex. Both follow the same principle: check for duplicates first, and read the results after submission.
Ask: How can I know which ones didn't come in after the interruption?Answer: Rely on the query results by title before submission plus one round of logs. Skip those with 'already exists' in the title and 'submission successful' recorded in the logs; retry for failures or those not recorded.
Ask: Besides the import interface, what else can be done with the interface?Answer: High-frequency capabilities on the API call side also include document reading and writing, classification and tags, image upload, comments and reviews, friend links, system settings, etc., specifically according to the classification of the in-site interface documents.