Я-бы приветствовал строгость как естественный процесс приведения беспорядочного исходного
кода к более порядочному. Это знаетели... как переход с языка C на С++.
chopix, дружище. Ты вообще понимаешь как проектируется ORM? Ты описываешь entities. Описываешь сервисы (репозитарии). И методы. И работаешь через методы. Это и есть лучшие практики работы с ORM.
Если ты решил взять готовую базу и затащить все что можно в ORM то тогда тебе ORM не нужен. Бери SQL. Он универсальнее в данном случае.
Ну вот там Photo это табличка. А PhotoService.findAll - это метод которым можно читать таблицу. Бери как-то по аналогии. Я не знаю и читай как вообще работают с ORM.
Kroyzen, мы с чем боремся? С новым софтом. Или просто разработчик выдал новую версию? Если так - то image: менялся и попробуй верни старую версию. Если заработает - тогда пиши письма разработчику. Дескыть софт падает.
Тут два момента. Первое. Исходники должны лежать в репозитарии кода проекта. Git, Gitlab неважно. Это моя консервативная точка зрения старого разработчика. Когда они в репах - то их можно централизованно фиксить и распространять патчи. Особенно это удобно когда у тебя тыща серверов и десять енвайронментов.
Второе. Будут-ли они лежать в sql-файлах или в XML/Liquibase/Flyway или C#/Java сорцах - это особо не важно. Важно чтобы был минимальный объём дейтвий для внесения изменений. В идеале - ты в пятницу вечером заменил 'a' на 'b' сделал commit/push тег деплой и открыв банку пива пошел домой.
И всё. Никакие другие действия не нужны. Никтому ни звонить. Никаких админов не уговаривать. Вот как-то так.
JRBRO, ты от всего не подстрахуешся. Поэтому начитай с этого и пиши новые вопросы по ходу. Придумывать всякие угрозы для тебя и опасные места - это знаешь-ли неблагодарное дело. Короче получи свой опыт.
Володимир Паламар, насчет Kafka я точно не скажу. Но если нет балансировок и перезагрузок - тогда пропускная способность кафки почти бесконечна. Вот сколько машин в кластер загонишь на столько и умножать можно. Ну это грубая формула. Там на самом деле есть еще репликация.
А RabbitMQ - это я просто для общности сказал чтоб было с чем сравнивать. Можно даже взять Apache ActiveMQ. Это все из бесплантного. А по поводу недостатков. Эти все штуки хорошо работают в топологии точка-точка. Но если у тебя модель топиков-подписок то эти архитектуры ведут себя гораздо хуже чем кафка. Собственно ... Кафка это даже не MQ система. Это скорее распределенное хранилище логов сообщений. Вот поэтому ее и часто советуют в оппозицию к стандартным системам.
Володимир Паламар, сколько клиентов одновременно присутствуют? Согласно архитектуре Kafka каждый клиент - это consumer и его нужно настроить на топик или есть еще опция топик + партишен или ключ.
Успех архитектуры kafka будет зависеть от того сможете ли вы разложить producers/consumers/partitions оптимальным образом иначе у вас все будут вычитывать всё.
При скорости в 500 машин по 0.05 сообщений в сек получаем средний канал 25 сообщений в сек. При такой нагрузке Kafka не нужна. Можете брать RabbitMQ.
Василий Банников, есть некие побочные эффекты от вендоров. Например Oracle поддерживает так называемую ORGANIZATION INDEX таблицу. Это по сути гибрид таблицы и индекса. И он поддерживает физический ордеринг в соотвествии с ключом или группой ключей.
И если вставлять так в первой сессии так.
INSERT INTO test_table (session_id, name) VALUES ('2022/06/09-SID001','A');
И в другой сессии загрузки так session_id='2022/06/09-SID002' то строки будут группироваться вокруг сессионного ключа. И при select мы будем видеть иллюзию ордеринга по сессии.
Но другое дело что в Oracle IOT-таблицы не расчитаны на bulk и имеют другие лимиты на длину данных.
Разумеется это в PG не работает.
И конечно реляционная алгебра вообще понятия не имеет об IOT таблицах.
Я не согласен с советчиками, которые советуют автору что-то купить или куда-то перейти. У него Linux/Samba и он ищет дешевое решения для реализации своих потребностей. Дешево и сердито.
Если его желание невозможно - то надо наверное написать что Samba так не умеет. Но никто пока этого не пишет.
Хочется понять, какую выгоду ищет автор. Какие-бы решения или хитрости ему не посоветовали для PG, это совсем не будет работать в других БД (Oracle, Mysql).
Реляционная алгебра определяет строки как множество. Это - не массив. Более того, даже если вы пинками ухитрились создать видимость порядка, любая операция вакуума или прочая усушка и утруска сегмента данных - разрушит это.
Там ничего вообще не надо переименовывать. Мы живем в век децентрализованных систем и облаков данных. Берите сразу имя картинки в виде UUID и пускай себе лежит хоть сто лет.
dostoevkiy22, мне кажется что у вас просто никогда не будет окончательно варианта капче-сети. И самое позорное что надо в этот стек втаскивать человека.
кода к более порядочному. Это знаетели... как переход с языка C на С++.
Злостные трюки перестали работать.