When PixivUtil2 executes a batch download by member or tag, for each image ID it will execute an API call to the pixiv site. In a rate limited program, API calls are a limited resource, and should be used/reused sparingly to avoid bans.
One approach to this is to cache AJAX API calls into the database. Whenever PixivUtil2 makes an AJAX call, it will first check the local database to see if such an AJAX call was already cached and is recent. Otherwise, it will fetch and cache/update said AJAX call.
A supplementary logic should be implemented perhaps, to invalidate outdated cached AJAX calls. At the same time, caching sizes can become large, so the user may delete old cached responses. Therefore, we may add the following options:
ConfigItem("Network", "cacheAjaxResponse", False)
ConfigItem("Network", "cacheAjaxResponseUpdatePast", 2_592_000) # fetch again if response older than 30 days
ConfigItem("Network", "cacheAjaxResponseDeletePastSeconds", -1) # never delete cached responsesThen, create a table like this:
CREATE TABLE IF NOT EXISTS cache_ajax_response (
ajax_url VARCHAR(255) PRIMARY KEY,
content TEXT,
created_date DATE,
last_update_date DATE
)
When PixivUtil2 executes a batch download by member or tag, for each image ID it will execute an API call to the pixiv site. In a rate limited program, API calls are a limited resource, and should be used/reused sparingly to avoid bans.
One approach to this is to cache AJAX API calls into the database. Whenever PixivUtil2 makes an AJAX call, it will first check the local database to see if such an AJAX call was already cached and is recent. Otherwise, it will fetch and cache/update said AJAX call.
A supplementary logic should be implemented perhaps, to invalidate outdated cached AJAX calls. At the same time, caching sizes can become large, so the user may delete old cached responses. Therefore, we may add the following options:
Then, create a table like this: