Постраничное удаление
Прикольная алгоритмическая задача, которая пригодится на собеседования кандидатов или для вящего удовольствия.
В базе данных есть заранее неизвестное количество контрагентов.
К базе можно выполнять только один вид запроса: спросить сколько контрагентов находится в выдаче на странице номер N.
При этом на странице выдается по 25 контрагентов и контрагенты всегда упорядочены одинаково. На последней странице может быть меньше контрагентов.
К запросу можно выполнить только одно действие: удалить контрагентов, выданных на странице.
При этом будут удалены только те контрагенты, по которым в базе не проходит никаких операций.
Вопрос: Как оптимально выполнить удаление всех контрагентов, которых можно удалить.
UPD: задача вызвала обширное обсуждение на Инфостарте, потому что довольно хитрая алгоритмически. Если любите математические задачки, сходите, почитайте, там интересно.
Сдается мне ты не нашел нормальный API у системы если какой-то костыль через браузер замутить захотел.
Если это веб страница, то запрос — это REST запрос. GET на получение, POST/DELETE на удаление. Смотрим какими параметрами манипулирует и что возвращает. Дальше пишем скрипт который получает список всех обьектов и удаляет их. Сильно сомневаюсь, что API удаления завязано на номер страницы в паджинации. Оно должно включать список ID обьектов какие нам надо удалить. А список обьектов мы GET-ом получить можем.
нет, твой способ не проще. К тому же система легко может защититься от такого HTTP через выполнение промежуточных JAVA-скриптов, что она и делает.
Я уже и сделал через Селениум.
Речь идет о ZOHO BOOK, у нее замечательное API, но на него есть лимиты использования в течении суток, т.е. ограниченное количество вызовов. А удалять можно только по одному объекту, увы.
Я реализовал массовое удаление через эмуляцию работы пользователя, все чистится круто. На работу пользователя ограничений нет, можно чистить по 25 объектов за раз (то что показывается на странице).
Странное решение с их стороны. В апи своей црм они разрешают просто через запятую до ста айди в одном запросе слать.
Сам удивляюсь, но вот тебе лимиты:
Paid Organization — 2500 API calls/day and 100 API calls/minute
Free Organization — 1000 API calls/day and 100 API calls/minute
И в API нет массового удаления.
JavaScript выполняются до запросов. Открой dev консоль в браузере и смотри какие запросы реально идут. Поставь Firefox Developer Edition для больших фич. Ты чтоль не знаешь как веб работает ? У тебя либо fetch либо XMLHttpRequest запросы шлет в итоге.
Какой конкретно их продукт используется и какое API ? Там все еще от тарифного плана зависит. У каждого запроса разный вес. Bulk write операции дороже стоят.
Да, вообще стоит помнить что попытки обойти правила использования подобных продуктов могут приводит к бану, а эмуляция действий пользователя хорошо отслеживается по статистике работы.. Своим решением ты можешь навредить.
Даже не хочу смотреть в эту сторону.
Вот смотри — ты получаешь текст страницы, выполняется джава, которая вычисляет некий ключ SECRET (она может его запрашивать с сервера), потом выполняется твой запрос в котором уже присутствует этот SECRET. И как ты будешь вычислять этот SECRET для запросов? Аналазировать java-код, выполнять джаву без ДОМ-модели (как?).
Такой способ потенциально не всегда работает, только в простейших системах, а zoho к ним не относится, там много защит.
Апи вот такое: https://www.zoho.com/books/api/v3/
Увы, для всех тарифных планов лимит:
Paid Organization — 2500 API calls/day and 100 API calls/minute
Free Organization — 1000 API calls/day and 100 API calls/minute
Бан вряд ли, CSV-загрузка, которую использую, гоняет намного больше данных, чем удаление, а на нее лимитов нет.
Да и речь о вводе остатков, если вдруг и бан, то можно новую базу занять. Удаление нужно, чтобы удалять неудачные загрузки
1. Вопрос не в обьеме данных а в политики лицензирования доступа. Система-то у них отдаст сколько угодно, все эти лимиты сугубо для выбивание бабла. А вот политику использования они могут блюсти жестко , как в онлайн играх за использование ботов. Настоятельно рекомендую точно проверить что твой способ не нарушает лицензионного соглашения. Возможно стоит написать письмо в службу поддержки с уточнением что такой подход ок. Иначе можешь подвести клиента , если это его аккаунт был.
2. Весь код какой в браузре исполняется — доступен и можно деобсфуцировать его. Возможно твой secret не вычисляется а получается с сервера с токеном авторизации. В этом случае и из скрипта его можно получить тем же образом. Надо анализировать текст запроса. А запрос как раз в консоли разработчика и можно посмотреть. И header-ы все и body и параметры.
Впрочем, если решил проблему — то ок, но на пункт 1 стоит обратить внимание.
Слишком много анализировать. И сам джава запрос и скрипт, причем без гарантии результата, по крайней мере быстрого. Эмуляция намного проще.
Находим крайнюю страницу циклом по количество строк на странице не будет равно 0.
От конца в начало удаляем постранично, внутри страницы тоже с конца.
Но лучше все таки изучить API.
Не совсем. Посмотри ответ на Мисте или подумай еще. Есть вариант поэффективнее.
На мой взгляд это принципиально ничего не дает, если конечно ты сможешь доказать обратное — я буду рад.
А если не дает, то чем проще описание алгоритма, тем он более устойчив к изменениям.
Так вот мой проще в описании.
тот алгоритм тоже не сложен в описании, интуитивно ясен и эффективен.
Сходи уже на мисту и посмотри.