История изменений

1. Да, были такие мысли. Но чё-то сложно-сложно на первом этапе. Есть всякие краевые фигни. Юзер вставил кусок текста в середину и одновременно ловко в конце точку поставил. Хоба, оно должно уметь уже нетривиальные диффы какбэ.
2. Да, вот это интересная идея. Была такая идея, в backend-процессе, к которому юзер держит коннект (а коннект может быть долгим и процесс, держащий его, живёт долго) можно в памяти складировать без базы. Надо это проработать. Вероятность того, что этот процесс сдох - не выше, чем собственно процесс «СУБД», с чего ему быть выше-то по идее, если сделано не граблями. Ну может и чуть выше, потому что всё-таки это «бизнес-логика», а её принято пилить костылями почему-то.
3. Сложно реализуемо чисто по принципу устройства наших баз, ну точнее я это пытался описать в первом посте. Там у меня эта запись лежала в отдельной табличке-хештабличке, где она может быть только одна, а потом база САМА её перекладывала по команде «move из одного в другое» - тут надо базу чуть подпилить.
4. Да, такая тема была, обсуждалась, в стартовой месаге этому уделено вним., либо кому-то отвечал про это. Но ещё до написания топика была такая мысль, да - собственно это тот вариант, который описывается «кладём черновики в базу MESSAGES, а при постинге делаем атомарный MOVE из одной таблицы в другую». Тут дублирую сказанное в (3).

Идея с «очередью» тут конечно самая годная. Точнее не очередь, а тупо хештабличка вида [(uid, chat_id)] => Message в памяти backend процесса, который сейчас держит коннект к этому клиенту. Процессов таких конечно может быть много, ибо может быть пошардено-пореплицировано ради нагрузки. Message - это черновик. Досылы этого черновика просто апдейтят эту [(uid, chat_id)] => Message в памяти. Процесс упал - черновики просраны за последнюю минуту. Но тут дело такое: «чо бы ему падать-то, пишите код без ошибок, базу же написали как-то».

В целом да, интересное направление: за счёт известной степени необязательности-роскошности фичи «черновики» можно расплатиться за вероятность падения backend-процесса, который черновики держал в RAM… Быстро, дёшево, модно, базу не пинают.

1. Да, были такие мысли. Но чё-то сложно-сложно на первом этапе. Есть всякие краевые фигни. Юзер вставил кусок текста в середину и одновременно ловко в конце точку поставил. Хоба, оно должно уметь уже нетривиальные диффы какбэ.
2. Да, вот это интересная идея. Была такая идея, в backend-процессе, к которому юзер держит коннект (а коннект может быть долгим и процесс, держащий его, живёт долго) можно в памяти складировать без базы. Надо это проработать. Вероятность того, что этот процесс сдох - не выше, чем собственно процесс «СУБД», с чего ему быть выше-то по идее, если сделано не граблями. Ну может и чуть выше, потому что всё-таки это «бизнес-логика», а её принято пилить костылями почему-то.
3. Сложно реализуемо чисто по принципу устройства наших баз, ну точнее я это пытался описать в первом посте. Там у меня эта запись лежала в отдельной табличке-хештабличке, где она может быть только одна, а потом база САМА её перекладывала по команде «move из одного в другое» - тут надо базу чуть подпилить.
4. Да, такая тема была, обсуждалась, в стартовой месаге этому уделено вним., либо кому-то отвечал про это. Но ещё до написания топика была такая мысль, да - собственно это тот вариант, который описывается «кладём черновики в базу MESSAGES, а при постинге делаем атомарный MOVE из одной таблицы в другую». Тут дублирую сказанное в (3).

Идея с «очередью» тут конечно самая годная. Точнее не очередь, а тупо хештабличка вида [(uid, chat_id)] => Message в памяти backend процесса, который сейчас держит коннект к этому клиенту. Процессов таких конечно может быть много, ибо может быть пошардено-пореплицировано ради нагрузки. Message - это черновик. Досылы этого черновика просто апдейтят эту [(uid, chat_id)] => Message в памяти. Процесс упал - черновики просраны за последнюю минуту. Но тут дело такое: «чо бы ему падать-то, пишите код без ошибок, базу же написали как-то»

1. Да, были такие мысли. Но чё-то сложно-сложно на первом этапе. Есть всякие краевые фигни. Юзер вставил кусок текста в середину и одновременно ловко в конце точку поставил. Хоба, оно должно уметь уже нетривиальные диффы какбэ.
2. Да, вот это интересная идея. Была такая идея, в backend-процессе, к которому юзер держит коннект (а коннект может быть долгим и професс держащий его долго живут) можно тупо в памяти что-то складировать без базы. Надо это проработать! Годная тема вообще. Вероятность того, что этот процесс сдох - не выше, чем собственно процесс «СУБД», с чего ему быть выше-то по идее, если сделано не граблями.
3. Сложно реализуемо чисто по принципу устройства наших баз, ну точнее я это пытался описать в первом посте. Там у меня эта запись лежала в отдельной табличке-хештабличке, где она может быть только одна, а потом база САМА её перекладывала - тут надо базу чуть подпилить.
4. Да, такая тема была, обсуждалась, в стартовой месаге этом выделена часть букв даже, либо кому-то отвечал про это. Но ещё до написания топика была такая мысль, да - собственно это тот вариант, который описывается «кладём черновики в базу MESSAGES, а при постинге делаем атомарный MOVE из одной таблицы в другую».

Идея с «очередью» тут конечно самая годная. Точнее это даже не очередь, а тупо хештабличка вида [(uid, chat_id)] => Message в памяти backend процесса, который сейчас держит коннект к этому клиенту. Message - это черновик. Досылы этого черновика просто апдейтят эту [(uid, chat_id)] => Message в памяти. Процесс упал - черновики просраны. Но тут дело такое: «чо бы ему падать-то, пишите код без ошибок, базу же написали как-то»