ок. Только обещай мне не использовать paper_trail для задачи

если у него проект весомый, то весьма важно, как оно хранится

ок. Только обещай мне не использовать paper_trail для задачи

без проблем :) Задача в принципе теоретическая. Из разряда я хочу в будушем проекте в котором еще даже init комита нету запилить такую фичу.

ну на самом деле нет

преждевременная оптимизация зло

Важно дойти до хайлоада

Я спрашивал тут как то как оптимизировать запрос

Over time your versions table will grow to an unwieldy size. Because each version is self-contained (see the Diffing section above for more) you can simply delete any records you don't want any more.

Мне сказали ты дойти до хайлоада и будем на деле смотреть как лучше сделать

а если он уже на хайлоаде?

При чем тут преждевревенная оптимизация если это типа и есть "основная фича"

да, на проде повыполнять запросы, которые идут по 10 минут?

чтобы просрать все полимеры?

а если он уже на хайлоаде?

ты думаешь человек который работает с хайлоадом будет задавать вопрос о версионности модели?

если берешь новый гем - надо адекватно понимать его минусы

лолчто?

что, не видел запросов на 10 минут?:)

на 10 минут что?

запрос, который 10 минут выполняется базой

Ну 10 минут не видел. Видел минуту

И это было у проекта с базой в пару десяткой ГБ

И один раз и лиды это быстро поправили

достаточно было переписать логику запроса и подчистить незамеченные n+1

ну я за лидов рад, но я о том, что на проде тестить немного хуевая идея

проект пришел в поддержку

Давай будем писать супербыстрыйправильный код на dry-rb и rack

тогда ты точно не проебешь проект

Давай будем писать супербыстрыйправильный код на dry-rb и rack

зачем?

Вот и я говорю, зачем думать о проблеме, пока ее нет

Проблемы надо решать по мере поступления

у них в документации написано "База быстро разрастается"

Да это ясно и так

Если ты сохраняешь документ по 100 раз в день то да

если миллион пользователей будут по 10 раз в день сохранять то надо будет думать об этом

У меня был проект с 10млн пользователей и папертрейлом

и никакой боли в нем не было

ну если у тебя не было проблем, а в доках сказано, что они вполне вероятны - то это не значит, что проблем не будет?)

тем более, что они реально сохраняют весь объект, а не диффы

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

например последние 5

для документов точно надо диффы сохранять

и делать опорные точки

вот и я о том, что хранить доки целиком в базе - сомнительное решение

цена разработки/проектировки = результату/полезности?

в смысле? Разве гема нет для версионирования?

Нужно посмотреть, кто внес изменения в док месяц назад - последние 5 изменений тут не особо помогут

Ну и будешь ты в соседнюю табличку дифф складывать какой вообще профит

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

профит в размерах базы

ну строки также будут плодится быстро

а какой профит в гите? Взял, откатился на любую версию по диффам. И сможешь посмотреть, когда что было изменено

просто будет меньше полей

нет, гораздо меньше будет

ну как нет. Изменил я текст, записал

Текст не поменялся не записал

да, поменял ты строку - а пересохранился весь текст

в paper_trail так

ну тебе же надо видеть разницу

за много сохранений и иметь доступ к любой версии

что к 48 что к 13

да

paper_trail для такой задачи не подходит

Я опорные точки для дураков написал?

paper_trail для такой задачи не подходит

почему

как раз я могу жонглировать версией

любой

у тебя та хранятся все версии

не, у меня хранятся только изменения

ERROR: S client not available

если у меня не paper_trail

ну я даже не знаю, как тебе объяснить. Знаешь, почему гит сохраняет диффы файлов текстовых, а не целиком их?

a = Article.create a.versions.length # 1 a.update_attributes :title => 'My Title', :rating => 3 a.versions.length # 1 a.update_attributes :title => 'Greeting', :content => 'Hello' a.versions.length # 2 a.paper_trail.previous_version.title # 'My Title'

или с другой стороны начну - у нас на проекте одном был флеш. Там файлики бинарные - гит их пересохранял целиком. За 2 года проекта папка гита была около 70 Гб

притом сам проект весил около 7

не, тут идея в чем, в том что ссыте что база будет вырастать быстро

от каждого апдейта

И типа когда записи пойдут на десятки/сотни миллионов все это будет тяжело выбираться

Идея как раз сделать мини-гит в базе, а не сохранять всё подряд

Да я понял, вопрос это стоит того? У тебя реально миллионы пользователей в месяц, которые засрут тебе базу? у тебя реально нет денег чтобы когда это случится вложиться в оптимизацию и железо? Переписать выборку и отдачу на более быстрые решения? Поколдовать с кэшированием?

Я думал мы про быструю разработку и быструю прибыль

Все таки railsway

а что, хранение диффов каким-нибудь готовым гемом - настолько неприемлимая для тебя идея, что там бомбит?)

Прям

Вопрос не в том стоит или не стоит. А вопрос в том как реализовать такую фичу. Чисто спортивный интерес. О прибыли темболее нет речи :)

Просто эти диффы же он тоже будет тебе приводить в порядок

брать разницу подменять текст выдавать

это рубя

она медленная и тупая

про это тоже не забывай. Я думаю что очень логично на БД такое вешать

Меня учили что если чтото можно отдать БД пусть Бд это делает.

Она умная и быстрая

да, так и есть, но кто мешает сделать тогда тонкий клиент на фронте, небольшую прослойку и все в ней делать?)

ну и по идее для такой задачи монго подойдет, насколько я правильно понял

да, так и есть, но кто мешает сделать тогда тонкий клиент на фронте, небольшую прослойку и все в ней делать?)

также ничего не мешает сделать эту задачу за вечер и годами работать без боли

на готовом проверенном решении

?

главное чтобы проект не умер раньше, чем начнуться траблы с бдшкой

ой, да умереть может что угодно

тот же разработчик

я не вижу гема сейчас просто, который бы работал с диффами. Но если он есть и он адекватно написано - то вполне верю, что он там все сам хорошо разрулит на уровне бд

ну я поэтому и говорю что преждевременная оптимизация зло. Тогда раз такие сложности, может вообще от рельсы отказаться