Сейчас в тройке каждое изменение индексированного поля создаёт в индексе новую ноду, даже
если такая уже там есть. То есть последовательность апдейтов 1-> 2 -> 1 -> 2 -> 1 -> 2
оставит в индексе шесть нод, три с ключом 1, ещё три с ключом 2 и все будут ссылаться на
одну запись. Это так и задумано или недоработка?
Posted via ActualForum NNTP Server 1.5

dimitrВыходит, что все так и задумано.
Это хорошо. Это значит, что сборку мусора можно значительно упростить и ускорить, выкинув
из неё сбор всех версий записи. В этом случае тот фикс, о котором сейчас говорит Влад в
девеле, просто не понадобится.
Posted via ActualForum NNTP Server 1.5

dimitrапдейт - это вставка ключа (если ключевое поле изменено). Удаляет старые
ключи только сборка мусора. Выходит, что все так и задумано.
Проблема в том, что в текущем коде, из-за того, что list_staying() проходит весь список
версий, сборка мусора не удалит дублирующиеся ноды до тех пор, пока среди версий живо хоть
одно значение их ключа. Вообще, судя по этому list_staying(), дублирование нод должно было
отсекаться на этапе вставки значения в индекс.

Так что с одной стороны, оно - проблема, замусоривающая БД, а с другой стороны - позволяет
упростить чистку индекса при откате/сборке мусора тем, что для принятия решения об
удалении ноды не нужно собирать весь стек версий - достаточно двух или трёх.

Что по этому поводу думают архитекторы?
Posted via ActualForum NNTP Server 1.5

hvladПо какому ?
Почему эти два куска кода не согласуются между собой.
Posted via ActualForum NNTP Server 1.5

hvladМне надоело выковыривать из тебя слова.
Ну так научись задавать конкретнейшие вопросы. В жизни пригодится. Лично моей интуиции не
хватает чтобы протелепатить что именно тебе непонятно в описании выше.
Posted via ActualForum NNTP Server 1.5

TPAKTOPAКак мне кажется, Dimitry Sibiryakov имеет ввиду, удалять старые ключи в
индексе (чистить мусор) ещё при вставке нового значения.
Не, я, конечно, местный клоун и вообще тупой, но не настолько же.
Posted via ActualForum NNTP Server 1.5