On Thu, 24 Aug 2023 at 16:40 +0300, you wrote to me:
AF>> Это проблемы кривого софта типа SmapiNNTPd, а не пуржилки. NA> Пример, надо тебе написать софт, который сразу может прыгать на 10ое NA> сообщение из JAM базы. После пуржинья, предположим, это сообщение NA> стало 5ым. Линеный поиск сообщения по всей базе не предлагать O(n).
Такой софт должен импортировать сообщения в свою базу, предназначенную для таких специфичных действий. Либо строить какой-то свой индекс, например, msgid+from_address:number, чтобы после пуржинга можно было перестроить индекс и быстро находить актуальный номер нужного сообщения.
AF>> Упаковать JAM базу без сброса BaseMsgNum, наверное, возможно, но AF>> это крайне тупо. NA> Решение в том, что я хочу прыгнуть не на 10ое сообщение порядковое в NA> базе, а именно 10ое.
Нельзя расчитывать на то, что у сообщения в базе (Jam, Squish) есть какой-то перманентный абсолютный номер. В теории, можно написать пуржилку, которая будет сохранять номера писем, оставляя дырки в индексе, но такая пуржилка никому, кроме держателей странного софта, не нужна, поэтому вряд ли кто-то будет это делать.
NA> После пуржинья, например, BaseMsgNum выставился в 5
После пуржинга он должен выставиться в 1 и больше никогда не меняться вообще.
AF>> Вообще, BaseMsgNum - это рудимент, нормальный софт его не AF>> трогает. NA> В спеке он есть. Нормальный софт всегда высчитывает номер сообщения NA> прибавляя BaseMsgNum.
Всё верно, потому что если какой-то древний софт зачем-то меняет BaseMsgNum, то любой другой софт должен это учитывать. Но при пуржинге (а точнее при упаковке) оставлять BaseMsgNum отличным от 1 - как минимум странно.
В спеке указан только один юзкейс для этого - удалить первые N сообщений в базе, точнее, сделать их "недоступными". Это явно было придумано до того, как сделали soft delete. Сейчас в этом смысла нет.
