Как реализовать кастомную систему контроля версий комментариев на JS/TS?

Question

[partyzanx]

Делаю проект на node.js, express.js, react.js.

Необходимо реализовать кастомную систему контроля версий комментариев пользователей на JS/TS, чтобы можно было отслеживать все изменения их комментариев, чтобы это всё в последствии отнимало как можно меньше памяти.

Можете примерно объяснить логику как это сделать? И в каком направлении думать?

Comments

[GavriKos]

А git тут причем?

[partyzanx]

GavriKos, по сути надо на минималках воссоздать логику работы Гита

[GavriKos]

partyzanx, а почему тогда нет тега svn, perforce, plastic?
Теги не так работают. Да и не надо вам тут ничего из того что умеет гит по сути. Совершенно другие единицы атомарности.

[Сергей Кузнецов]

Комментарии так часто исправляют, что потребовалась система анализа этих изменений?

Если же речь про расход памяти. то это уже не про контроль версий, а про систему хранения комментариев.

Определитесь, что именно вам нужно? Компактное хранение или контроль версий?

И вы не поверите, но гит в каждом коммите изначально записывает полную версию каждого измененного файла. Уже потом, в фоновом режиме оптимизирует своё внутреннее хранилище объектов.

[partyzanx]

Комментарии так часто исправляют, что потребовалась система анализа этих изменений?

Да

гит в каждом коммите изначально записывает полную версию каждого измененного файла. Уже потом, в фоновом режиме оптимизирует своё внутреннее хранилище объектов.

Как он выявляет разницу с предыдущим коммитом? Хотелось бы этот же механизм понять и накастылить на JS / TS

Answer 1

[Сергей Соловьев]

Когда пользователь изменяет комментарий, то создается новая версия этого комментария.
В БД лучше сделать дополнительный столбец, указывающий на ID нового комментария: когда происходит изменение, то обновляешь этот столбец - указываешь ID новой версии.

История получается линейной, чтобы восстановить историю - находишь последний без установленного этого ID

Comments

[partyzanx]

Это слишком дорого для памяти сохранять при каждом изменении новую версию комментария.

[Алексей Ярков]

partyzanx, а какие ещё есть варианты чтобы историю хранить? ))

[Saboteur]

partyzanx, То есть дорого??
Храните в базе, а не в памяти.

[partyzanx]

Алексей Ярков, примерно как работает Гит

[partyzanx]

Saboteur, бд занимает память

[Алексей Ярков]

partyzanx, не фантазируйте )) Вам предложили отличный вариант, прислушайтесь.

[partyzanx]

Алексей Ярков, вариант не отличный

[Алексей Ярков]

partyzanx, ну удачи тогда

[Сергей Соловьев]

partyzanx, ну иначе можно сделать так:
1. Каждый раз вычислять дельту изменений с предыдущим комментарием (+CPU время)
2. Добавить столбец по типу "History", который будет хранить массив этих изменений (+Место)
3. Чтобы получить актуальное состояние:
- Либо берем исходное сообщение и применяем дельты
- Либо сразу храним обновленное состояние

?

[partyzanx]

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

[Сергей Соловьев]

partyzanx, на сколько мне известно, гит не смотрит на содержимое строк (сами символы) - он подсчитывает хэш строки, и так определяет какая строка добавилась, какая изменилась или удалилась.
Короче, он сохраняет целые строки, а не символы.

[Saboteur]

partyzanx, БД занимает ровно столько, как вы ее настроите.
Ну и в принципе. не делайте тогда ничего, ибо чтобы вы не сделали - все будет занимать память.

[chemdev]

partyzanx, А есть данные как часто юзеры меняют комментарии? По моему не так часто, чтобы отношение памати на дополнительные версии к памяти на комментарии было сколько либо значимым, но это лишь гипотеза.

[Kentavr16]

вариант на тему - можно оборачивать изменения комментария в тег с версией комментария и действием. К примеру при удалении строки не фактически удаляешь ее из текста, а оборачиваешь в условный тег commentDaletePart v=2.Далее при запросе комментария парсишь только последнюю версию. Это так, фантазии на тему танцев с бубнами.

[partyzanx]

Kentavr16, да так можно, только вопрос как это отследить)))

Была идея отслеживать через браузерные события, типа где-то ставишь курсор, там появляется инпут, вводишь данные, хотя для пользователя это незаметно, он будет думать, что продолжает писать в общем поле)

[Сергей Соловьев]

partyzanx, это называется расстояние Левенштейна

[Kentavr16]

partyzanx, есть библиотеки отслеживающие разницу двух строк с неплохим функционалом.

[Kentavr16]

partyzanx, но всегда нужно держать в уме что единственный нормальный вариант уже предложен в ответе. Жалеть пространство на хранение старых версий текста это странно. И после всех изменений это будет точно не про оптимизацию

[partyzanx]

Kentavr16, я побежал искать, но прошу подсказать ещё варианты