Ну у меня еще оперативы есть свободной, а он его юзает. За месяца два накапливается примерно 10 гигов свопа из которого работаю программы и работают они понятное дело медленно. Перезагружать ноутбук я не люблю, так как переподнимать разные проекты не очень то удобно.
На счет локал хоста понял. На счет имен сервисов не уверен, что правильно. Доказать не могу, но вроде где-то это работало и именно с этой целью создается общая сеть в разных docker-compose, как я думаю. То есть в одном она создается, а в другом сервисы подключаются к ней как к внешней. И в целом это работает ведь, раз они видят друг друга. Плюс я видел и не раз в разных сервисах, в .env файлах адреса других сервисов с использованием имени этого сервиса. То есть в .env файле сервиса A идет переменная c адресом service-b и переменная с портом для этого сервиса, а потом в коде идет обращение курлом из сервиса А в сервис B. Значит это как-то все таки должно работать.
Да, это верно) Вообще я принял решение продолжить писать дополнительные поля в этой таблице. Вы правы, что тут нужен рефакторинг, но пока на него нет задачи, а значит вариант остается писать в таблицу, потому что отделять одно поле в отдельную таблицу это много накладных расходов. Если бы с нуля делал, то так бы и сделал, а так нет смысла. Вообще таблицы настроек для других таблиц это хорошая практика, позволяет например легко делать логирование настроек.
Владимир Коротенко, можно чуть подробнее, почему нет? Если появятся дополнительные настройки, то либо будем кашу лепить, либо нормализовать, выделяя данные в отдельные таблицы и рефакторить код, завязанный на них. Я думаю, что изначально в этой таблице тоже было одно поле настроек, а потом начали лепить второе, третье и так далее, а теперь каша из полей неизвестно для чего. Чисто ваше мнение.
Не понял, если честно юмора. Никто ни куда ничего не переносил. Как часто вы приходите в крупную компанию и занимаетесь новым проектом? Не часто, думаю. Вот ты приходишь, есть проект, которому больше 3 лет. Есть много сервисов, их базы данных и так далее. И вот там так все через одно место сделано. Разумеется тебе никто не даст времени рефакторить. Да, лежит все в одной таблице, да не по нормальным формам, но работает и начальству это важно, а не феншуй. Да и вопрос не в этом и не в том, кто виноват. Вопрос в том, когда пишешь новый функционал, есть ли смысл выносить каждое поле, не имеющее прямого отношения к таблице в отдельную таблицу? Я встречал разные подходы. Кто-то все лепить в одну таблицу, забивая на нормальные формы, и говорит - меньше ключей - лучше. А кто-то каждое поле выносит в отдельную таблицу следуя нормализации. Вот я хочу понять, где эта грань, между выносим из общей таблицы в настройки или или пихаем туда. У меня только один флаг, есть ли его смысл добавлять в отдельную таблицу или нет?
Akina, я думаю, что тут никто никакие нормальные формы не выбирал. Проекту больше 3 лет и развивался он просто спонтанно, тут разработчиков поменялось, наверно, не мало. Обычно как - кому как удобно, тот так и делает. Кто-то все в одну таблицу пишет, кто-то в разные. Я еще не встречал проектов, где целенаправленно выбирают какой формы придерживаться, прописывают в документации и применяют. Тут документации то у проекта в целом нет почти, так, общие описания. Меня интересует именно частный случай.
Это таблица куда кладутся данные в том формате как они приходят от сервиса. То есть одна таблица с примерно 30 колонками, где лежит куча данных в перемешку. Кто это так придумал и почему знает только тот, кто придумал, но он тут уже не работает, а я тут совсем недавно. Есть задача - грид с фильтрацией по любым полям - если в полет текст, или guid ищем не строго, а по вхождению части строки. Таких полей там много, например разные данные о ходе проведения транзакции. Все это дело дергается по api. То есть дергаются данные с пагинацией из таблицы. Потом строятся списки фильтров через distinct по этой же таблице. Да, если бы данные, которые можно условно считать справочными лежали бы в отдельно проиндексированной таблице, то это отрабатывало бы почти моментально, но тут я еще не разобрался, на сколько будет болезненно это исправить. Это надо одну таблицу разбить на много других, прописать связи и переписать весь код, который работает с этим делом, а это не меньше трех лет работы с этой таблицей) В общем я пока думаю, как тут меньшей кровью обойтись и можно ли так сделать.
Этому проекту не один год и лепили его все как могли, я уже пришел на этот прекрасный проект, когда он так спроектирован. Сейчас понятное дело рефакторю. Когда скопилось такое количество данных, то перестройка базы данных не такая тривиальная задача, чтобы взял и раскидал. Там дамп одной таблицы 70+ гигов. Плюс отдельные таблицы это тоже не всегда фонтан, так как это индексы, индексы вообще не всегда ускоряют работу. Иногда от них вообще отказываются полностью, но это разумеется не тот случай, тут просто так программист работавший на проекте решил сделать.
Для работы с json есть свои методы в postgresql.
like идет только по полям типа project_name. Где не предусмотрен большой объем текста. На счет полнотекстного поиска буду разбираться. Я им не пользовался пока, не было нужды так сказать. Но избегать поиска по этим полям не получится, так как нужно прямо из грида фильтровать по ним и сортировать.
Максим Тимофеев, а на счет кнопки выводить все, ее можно как-то настраивать? У меня просто данные по api получаются из другого сервиса. Получаются разумеется исходя из номера страницы, то есть по номеру страницы получаем нужный offset и с ним отправляем запрос на другой сервер для получения данных. Вот можно как-то вообще сделать так, чтобы таскались данные отдельным запросом при нажатии на кнопку для показа всех записей? Не сталкивались с таким?
Ду суть в том, что перегрев от подключения монитора это странно) Причем я заметил, что это только при подключении через Thunderbolt, с hdmi все норм, но хочется два монитора подключать. Мой старый ноутбук асус лет 10 которому не греется от мониторов внешних. Хотя он слабже на порядок этого мака.
Так там попробуй в кучу говнокода засунуть новые модули) Это когда ты скачиваешь чистый фреймворк как говорится в одной коробке и на его основе пилишь приложение это да) А когда у тебя куча кода написаного через одно неприличное место и его нужно отрефакторить, вот это вот решение с попутным изменением каркаса, тут нужно сто раз подумать) Потому что в целом переписать это все будет не так просто)
А что там вообще нового и полезного, что делает его лучше старой версии? Что-то в архитектурном плане поменялось? Или те же AR и связанные модули?
Перемонтировтаь пробовал, но пишет что успешно смонтирован диск, а толку нет.
Такого процесса не нашел.