= Сообщение: 2185 из 2735 =================================== RU.FTN.DEVELOP =
От : Alexey Fayans 2:5030/1997 25 Aug 23 09:15:16
Кому : Nil A 25 Aug 23 09:15:16
Тема : BaseMsgNum в JAM
FGHI : area://RU.FTN.DEVELOP?msgid=2:5030/1997@fidonet+64e855ec
На : area://RU.FTN.DEVELOP?msgid=2:5015/46+64e83412
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.FTN.DEVELOP?msgid=2:5015/46+64e8c05a
==============================================================================
Hello Nil!
On Fri, 25 Aug 2023 at 07:25 +0300, you wrote to me:
AF>> Такой софт должен импортировать сообщения в свою базу,
AF>> предназначенную для таких специфичных действий.
NA> А вот и нет. Мне, лично, не симпатизируют все те разрабы, что
NA> засовывают сообщения в SQL, например. Засунули, свои какие-то там дела
NA> порешали, и всё, больше ни с кем не совместимо - пример тому JNode.
Значит ты любитель костылестроения.
NA> А тут, мы берём, чиста по спекам, и всё работает, и со всеми
NA> совместимы. Только не все спеки читают, и пуржиют, как им в голову
NA> взбредёт.
Изначально речь шла о сортировке, а не о пуржинге, и как ты себе представляешь сортировку без смены номера сообщения?
Да и спеки никто не нарушает делая renumbering даже без сортировки. При упаковке это нормальная история. А вот оставлять дыры в индексе ради сохраниения номеров сообщений - это костыли, нужные только для работы специфичного софта, который вместо того, чтобы использовать нормальную БД, пытается работать с не предназначенной для таких целей JAM-базой.
AF>> Либо строить какой-то свой индекс,
NA> Ага, типа как ластрид файлик, который опциональный, но про него хоть
NA> знают все, и его обновляют (иногда). Так то я и full-text search
NA> индекс могу положить рядом, чтобы поиск работал сразу, но это всё
NA> НЕСОВМЕСТИМО.
Это и не должно быть совместимо, потому что нужно только одной специфичной софтине. И класть это нужно рядом с этой софтиной, а не с JAM-базой.
AF>> Нельзя расчитывать на то, что у сообщения в базе (Jam, Squish)
AF>> есть какой-то перманентный абсолютный номер.
NA> Дану? В Сквише есть этот самый UMSGID (Unique Message Identifier).
Это не номер сообщения в общепринятом понятии. В JAM прямо в заголовке есть MSGID, OADDRESS и DADDRESS, этого вполне достаточно для использования в качестве уникальной сигнатуры.
NA> В Джаме есть номер сообщения в заголовках, но за константное время
NA> туда можно также добраться через BaseMsgNum прям.
Если быть точным, то BaseMsgNum нужен только для того, чтобы посчитать относительный номер сообщения, зная абсолютный, чтобы через JDX найти позицию заголовка в JHR и сделать туда fseek().
Я ещё раз хочу подчеркнуть, что BaseMsgNum в разговоре о том, что пуржинг (точнее упаковка) может привести к изменению абсолютных номеров сообщений, не играет вообще никакой роли. Это всего лишь часть механики по вычислению относительного номера, зная абсолютный, и наоборот.
NA> Например, хаски под низом использует smapi библиотеку, и там
NA> постоянные вызовы MsgMsgnToUid и MsgUidToMsgn, не знаешь зачем?
Я с этой либой не знаком, поэтому ХЗ.
AF>> В теории, можно написать пуржилку, которая будет сохранять номера
AF>> писем, оставляя дырки в индексе, но такая пуржилка никому, кроме
AF>> держателей странного софта, не нужна, поэтому вряд ли кто-то
AF>> будет это делать.
NA> А знаешь сколько у разных утилит есть опций?
Для опций нужен код. Этот код кто-то должен написать. Я к тому, что никто такой код писать не будет, потому что нафиг это не нужено. Ибо <тут известная цитата про бедуинов>.
NA>>> После пуржинья, например, BaseMsgNum выставился в 5
AF>> После пуржинга он должен выставиться в 1 и больше никогда не
AF>> меняться вообще.
NA> Ну окей, в мире котором ты живёшь, там BaseMsgNum==1 всегда. Есть
NA> вариант, когда он не 1? Если ты начинаешь новую базу, то он 1, если
NA> продолжаешь старую, то уже не 1.
Нужно один раз делать упаковку такой старой базы, чтобы BaseMsgNum стал 1 и больше никогда не менялся. Поменяются абсолютные номера сообщений, зато относительные сохранятся (если не было удалений или сортировки).
NA> Пойдём от обратного. Если BaseMsgNum есть, и учавствует в арифметике
NA> номеров сообщений, значит оно кому-то надо.
Ты как будто бы вообще не читаешь, что я пишу. Не вижу смысла писать по кругу одно и то же.
NA> Иначе бы такое поле не делали.
Его сделали когда-то давно, и его единственная задача - скрыть N сообщений с начала базы. Например, чтобы поддерживать фиксированное максимальное количество сообщений в базе без упаковки и пуржинга. Всё. Если у тебя в какой-то базе BaseMsgNum не 1, значит когда-то давно у тебя был настроен лимит сообщений. Если он у тебя всё ещё настроен, то регулярное изменение BaseMsgNum оправдано. Если нет, то нужно упаковать базу и забыть об этом.
AF>> Всё верно, потому что если какой-то древний софт зачем-то меняет
AF>> BaseMsgNum, то любой другой софт должен это учитывать. Но при
AF>> пуржинге (а точнее при упаковке) оставлять BaseMsgNum отличным от
AF>> 1 - как минимум странно.
NA> Как минимум ты не понимешь юзкейс, почему BaseMsgNum может быть не 1.
Я понимаю, а ты точно понимаешь?
... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20230214
* Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
|
