где-то в лёрне обсуждали

я там зобанен

за фашызм

я там зобанен

ну не повезло

эх жалко, шо Jeka Борисов про это видасы не снимал

наверное, как-то можно было бы в бинфакторипостпроцессоре в биндефинишне репозитория инфу подправить...

найс фреймворк

найс фреймворк

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

но я хз, не шарю

гемора больше будет

Согласен. По любому должна быть аннотация. Главное найти нужную.

Согласен. По любому должна быть аннотация. Главное найти нужную.

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

Сделать свой поджо, повесить и мапстрактом тудасюда

Гонять из ДТО в ДТО - весело однако

Сделать свой поджо, повесить и мапстрактом тудасюда

явно не это требуется

лан, мб я в тилте, не соображаю

явно не это требуется

От чего же. Есть поджо, где то в другой либе. Его не поменять, но нужно отрегулировать к примеру тот же Джексон. Что делать ?

что отрегулировать?

Нужно больше ДТО

Имя поля при сериализации

погоди

ты что-то другое говоришь

Диоген у тебя в итоге какая задача?

Диоген у тебя в итоге какая задача?

У меня изначально задача описанная сверху - для спринг даты юзать поджо без аннотаций

ну вот

Топик про Джексон я стартовал в защиту спринга

причем тут джэксон

мэпстракт

и прочее?

https://stackoverflow.com/questions/29082749/spring-data-jpa-map-the-native-query-result-to-non-entity-pojo

тебе что-то вроде этого надо

Топик про Джексон я стартовал в защиту спринга

Вот причем

Только придется писать hql или нейтив, и ещё маппинг

маппинг сделает дата

она умеет

эту задачу решил уже @igorz

там вроде баг был, но потом починили

Я только помню что багфикс был для этого

@igorz https://stackoverflow.com/a/42905382

https://jira.spring.io/browse/DATAJPA-980

в общем проверил, все отлично работает в таком виде. Причем этот метод я специально положил в репозиторий не User @Query(value = "select id from users", nativeQuery = true) List<IdOnly> findAllProjectedBy();

public interface IdOnly { long getId(); }

да, выше уже Дима скинул баг и где его пофиксили

1.10.12 (Hopper SR12), 1.11.8 (Ingalls SR8), 2.0 GA (Kay)

https://jira.spring.io/browse/DATAJPA-980

нашел переписку

https://stackoverflow.com/questions/29082749/spring-data-jpa-map-the-native-query-result-to-non-entity-pojo

У меня не жпа, а эластик, ну и спринг дата же коллекцию ещё создаёт по метаданным, индексы всякие, хз кароч

У меня не жпа, а эластик, ну и спринг дата же коллекцию ещё создаёт по метаданным, индексы всякие, хз кароч

ну да

я прям сразу догадался

что у тебя эластик

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

просто так этого не сделать

Тут появился такой странный момент, будто тароканоедство какое-то. В общем. Это нормально хранить pdf в виде байтов в базе данных, каждая запись по 1.5 мб?

вообще, не очень ?

Тут появился такой странный момент, будто тароканоедство какое-то. В общем. Это нормально хранить pdf в виде байтов в базе данных, каждая запись по 1.5 мб?

Встречный вопрос, бтв. Нормально ли хранить данные в файловой системе, записывая в базу относительный путь до него?

нормально, но лучше использовать абстракцию файловой системы

с поддержкой кластеризации для отказоустойчивости и фишками типо авто бэкапа и тд

например Amazon S3, Ceph

Тут появился такой странный момент, будто тароканоедство какое-то. В общем. Это нормально хранить pdf в виде байтов в базе данных, каждая запись по 1.5 мб?

на прошлой работе так делали, бывали и побольше пдфки

с поддержкой кластеризации для отказоустойчивости и фишками типо авто бэкапа и тд

вот это хорошо, аж душа радуется от таких слов

вообще, не очень ?

Почему?

на прошлой работе так делали, бывали и побольше пдфки

хотя чёт подумал и теперь не уверен

хотя чёт подумал и теперь не уверен

ну оно работало?

шо еще надо ппц

ну оно работало?

я не помню, где именно пдфки хранились и хранились ли вообще)

ERROR: S client not available

У нас щас так, в оракле пдф по 30 мб, некоторые с 2006г. лежат

мммм, представляю веселые миграции

А ещё шаблоны для отчётов по 60 мб, тоже там, потом отдаются на толстый клиент и рендерятся формы

Почему?

1. Там, где пдф-ка 1.5 мб будет и больше. 2. Бинарное представление плохо хранится в БД (неоптимально). 3. Для этого есть файловая система или специализрованные решения.

Допустим, S3 ?

мммм, представляю веселые миграции

У них нет миграции, у них в свн хранятся именованные числами папки типа 178_1, есть специальный человек который берет все из папки и прогоняет на базе

^

шок контент

Я когда начал говорить за флайвей и диквибейз - меня чуть не сожгли

1. Там, где пдф-ка 1.5 мб будет и больше. 2. Бинарное представление плохо хранится в БД (неоптимально). 3. Для этого есть файловая система или специализрованные решения.

1. По моему размер не особо важен. 2. Это в какой именно? Если не нужен поиск по содержимому, то почему бы и не хранить? Главное, чтобы лежало в отдельной табличке, а в другой табличке была только ссылка на неё. 3. ФС не надёжна и не поддерживает ни транзакций, ни одновременного манипулирования. Придётся велосипеды вокруг этого строить. Специализированные решения - да. Но зачем, если уже есть БД, с которой умеют работать люди (бекапы, мониторинг и прочее)?

1. По моему размер не особо важен. 2. Это в какой именно? Если не нужен поиск по содержимому, то почему бы и не хранить? Главное, чтобы лежало в отдельной табличке, а в другой табличке была только ссылка на неё. 3. ФС не надёжна и не поддерживает ни транзакций, ни одновременного манипулирования. Придётся велосипеды вокруг этого строить. Специализированные решения - да. Но зачем, если уже есть БД, с которой умеют работать люди (бекапы, мониторинг и прочее)?

зачем транзакции и манипулирования для простого хранения?

большие блобы в базе давно уже анти паттерном считаются

если вы были в вакууме эти годы

зачем транзакции и манипулирования для простого хранения?

Ну у тебя произошёл ролбак, ты будешь хранить испорченный файл? Потом строить вокруг этого чистку?

А если файлы нужны по бизнесу. Вот надо хранить выданные системой документы в течении пяти лет в надежном виде.

Ну у тебя произошёл ролбак, ты будешь хранить испорченный файл? Потом строить вокруг этого чистку?

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

1. По моему размер не особо важен. 2. Это в какой именно? Если не нужен поиск по содержимому, то почему бы и не хранить? Главное, чтобы лежало в отдельной табличке, а в другой табличке была только ссылка на неё. 3. ФС не надёжна и не поддерживает ни транзакций, ни одновременного манипулирования. Придётся велосипеды вокруг этого строить. Специализированные решения - да. Но зачем, если уже есть БД, с которой умеют работать люди (бекапы, мониторинг и прочее)?

1. Важен. 2. Поиск по содержимому (т.е. по бинарнику?) 3. Если нужно вот это вот всё, то мы снова приходим к специлизированному решению ?

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

Ну говорю - велосипед строить придётся на уровне ФС)

Ну у тебя произошёл ролбак, ты будешь хранить испорченный файл? Потом строить вокруг этого чистку?

что мешает мне хранить их просто в файловой системе?

что мешает мне хранить их просто в файловой системе?

Я вообще не против их хранения на ФС. Можно и так.

https://softwareengineering.stackexchange.com/questions/150669/is-it-a-bad-practice-to-store-large-files-10-mb-in-a-database

А можно и в БД. Не вижу просто большой проблемы в этом

ознакомьтесь

какие проблемы

Спасибо за ссылку. В общем как там и сказано: в определенных случаях это имеет смысл. Собственно в этом и был мой посыл.

https://softwareengineering.stackexchange.com/questions/150669/is-it-a-bad-practice-to-store-large-files-10-mb-in-a-database

Вообще да, статья неубедительная

это не статья

а обсуждение

А если ещё и держать отдельную табличку в БД и в целевой табличке хранить только ссылку на id с БЛОБом то можно многие проблемы оттуда решить

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