Вендор 1СKiller сделал платформу ORM на Java JPA и некоторые базисные вещи (например компоненту\класс "справочник Контрагентов"). Допустим ORM поддерживает несколько СУБД , но классы используем только в одной выбранной СУБД
ORM - это про доступ к данным лежащим в БД через парадигму ООП, правильно? Сделать "справочник Контрагентов" можно было в такой ситуации разве что как демонстрационный пример, как оно работает, сам смысл применения ORM в том что такие вещи делаются тривиально в том проекте где требуются, если с помощью этого ORM создание справочника это скольконибудь нетривиальная задача эту стыдобу лучше бы где-нибудь прикопать и никому не показывать, т.к. есть production-ready решения в которых это делается за час.
Но ок, допустим речь идет о Keycloak - комплексная система работы с аутентификацией/авторизацией пользователей, и вам очень захотелось взять ее к себе в проект и приделать еще что-то. Не вопрос - вы затягиваете ее к себе в проект через dependency и используете что там вам из нее надо. Там и модели построены, и описаны, и разворачивание на разные БД предусмотрено.
Допустим вы создали еще какую-то таблицу, поверх нее модель, хотите в этой модели делать связи с какими-то моделями из Keycloak (вы уже изучили документацию и хорошо понимаете что делаете) - вообще не проблема, делаете нужные вам поля у себя в модели с указаниями типов, ORM обеспечивает вам корректное раскладывание данных по моделям которы вы сами не делали.
Вы захотели еще какой-то проект затащить и взять модели из него - да не вопрос, сверились что БД общее поддерживается, добавили скрипты подготовки БД (если надо) из этого проекта, затянули его к себе через dependency. Готово. Хотите создать модель которая будет иметь часть полей из одного проекта, а часть из другого - наздоровье, продумали план обработки сущностей (как читать/как сохранять/как обновлять) и вперед, ORM позаботиться о том чтобы все распихать по таблицам как вы решили.
Или я что-то в вашей схеме не понимаю, или вам бы чуть глубже ознакомится с имеющимися решениями, почитать документацию, примеры посмотреть как это все выглядит и работает.
Есть ощущение что у вас проблема на этапе осознания чего вы хотите:
Вы хотите чтобы поля ваших моделей видели коллеги и могли указывать в своих запросах? Вам достаточно просто вести разработку в одном проекте не в блокноте, любая современная IDE вам все покаже и расскажет про уже созданные в проекте модели.
Вы хотите сделать в одном проекте РАЗНЫЕ модели навешанные на одни и те же таблицы/колонки БД? Вы хотите странного, тут так не принято ну совсем - почитайте как должен быть устроен маппинг таблиц в рамках существующих ORM.
Без тумана тайного знания в мире Java вопросы решаются следующим образом:
Осознаете что же вы на самом деле хотите
Смотрите существующие инструменты максимально покрывающие вашу потребность
Если какой-то один инструмент не нашелся - пытаетесь делить задачу на более простые и снова смотрите что есть подходящего
И вот только когда вы убедились что ничего подходящего совсем нет среди готовых инструментов вы начинаете писать велосипед
То что вы не искали подходящие инструменты видно хотябы по тому что для мапинга ваших сущностей есть много готовых инструментов, (mupstruct/Dozer/в некотором объеме даже Jackson и т.д.) но вы пошли снизу - увидели в языке вроде бы подходящий инструмент для создания своего инструмента и давай свой велосипед изобретать. Это плохой подход, не надо так - вместо того чтобы изобретать уже изобретенное, покрытое тестами и рабочее, лучше бы сделали что-то действительно новое.
И да, если пишете на языке - соблюдайте принятый Code Style, иначе ваш код читать будете только вы.
производительность - выбирай более низкоуровневый язык
Приведенная "парадигма" очевидно никогда не была истинной - для того чтобы писать на чем-то "более низкоуровневом" и иметь от этого какой-то прирост производительности надо уметь писать на этом "более низкоуровневом" как минимум не хуже чем те кто писал "более высокоуровневые" инструменты
Может быть можно стабилизировать форму капли магнитным полем определенной конфигурации? Понятно что не для всех материалов, но там вроде сталь указана.
Есть ощущение что вы пытаетесь сидеть на двух стульях - с одной стороны хочется чтобы как ORM - Repository, Entity и работа на уровне объектов, а с другой чтоб было видно конкретный sql и писать по-сути его. Если хочется именно sql то для вашей задачи у Connection (https://docs.oracle.com/en/java/javase/19/docs/api/java.sql/java/sql/Connection.html) есть метод prepareStatement(String sql, int autoGeneratedKeys), он похоже что делает то что вам нужно. Подозреваю что все развитые библиотеки-помошники в работе с JDBC вкурсе об этой возможности и скорее всего у них есть более удобный способ утилизировать эти возможности.
Мне тоже очень понравился Vue 3, круто было познакомится с script setup (правда пару раз было слишком познавательно). Возвращаться обратно не хотелось, а в проде был Vuetify 2. В общем из имевшегося тогда выбрали Element Plus. По ощущениям он больше на десктоп ориентирован, графическая часть у него послабее в плане дизайна (сугубо личное впечатление, не могу внятно объяснить), но он был достаточно стабилен чтобы использовать, имеет прилично компонентов. Вцелом как замена подошел.
я бы положил перед испытуемой три одинаковых металлических бруска, два из которых были намагничены в противоположном направлении, а третий -- не намагничен), и попросить указать, где какой. Или вообще положить эти бруски в одинаковые коробки. И провести штук 10 таких экспериментов. Если каждый раз ответы будут правильные, то дальнейшее тестирование ни к чему и двойной слепой контроль тут даром не нужен
И, возможно, оказалось бы в итоге что вы не достаточно хорошо контролировали собственную мимику / немного по-разному предьявляли экземпляры испытуемой / что-то говорили в процессе и ваш голос немного менялся и т.п., и на самом деле суть феномена совсем в другом. Методика двойного слепого тестирования придумана не просто так.
То что вы описали это не задача, а ваше ее решение. Возможно у той исходной задачи, которую вы пытались решить генерированием миллионов объектов с несколькими стрингами внутри, есть лучшие решения на java.
Но если вы всерьез рассматривали вариант использовать UUID в качестве ключа, то получается в пакетах вендоров этот ключ может представляться строкой, а не числом. Вы не пробовали отдавать идентификатор как строчку-из-цифр, а не число?
Я правильно понимаю что у вас что-то сломалось на клиенте, и что бы это починить вы смело патчите серверную часть?
Если да то есть предположение что если сервер отдает валидные данные, а клиент на них ломается, то ошибка именно на клиенте, и именно там ее и нужно чинить.
Впринципе по статье уже понятно, что у вас критерий схожести - визуально похоже (в статье про синтаксис вспоминают постоянно), рекомендую при таком подходе наждачку и туалетную бумагу тоже вместе классифицировать - в названии и там и там "бумага", и та и та в руллонах...
Если бы вы собственную ссылку на вики прочитали внимательно, то как минимум нашли бы это:
Although Java and JavaScript are similar in name, syntax, and respective standard libraries, the two languages are distinct and differ greatly in design.
Если даже оставить за скобками претензии относительно использования модели в контроллере для представления данных ваша статья все еще плоха для новичков там, что содержит абсолютно не обязательные для воспроизведения вещи, которые зачем-то там присутствуют, и никак не комментируются.
Если не ошибаюсь основное назначение этой массивности - жесткость конструкции. Она критически важна если станок работает по шаблону, без обратной связи. Есть предположение что качественный контроль по оптическому каналу снимает необходимость столь монументальной жесткости - мясной токарь стоящий за станком бывает делает весьма точные штуки, а жесткость у него так себе
Из всей статьи так и не понял, основной плюс на который можно рассчитывать при использовании этого инструмента по сравнению с Postgres это отсутствие объемной документации?
По информации Forbes, после легализации параллельного импорта стоимость компьютерной техники и электроники для конечного потребителя может вырасти на 20-40%.
А может быть вы знакомы с методикой рассчета, использованного в этом прогнозе? Мне казалось что если что-то перестали привозить совсем, то у этого чего-то цены нет (т.к. нет предложений о продаже), далее мы должны какуют-то цену (полученную в результате использования схемы "параллельный импорт") поделить на несуществующую и получить что-то в диапазоне от 1.2 до 1.4 . Как-то очень непонятно, если есть данные - поделитесь пожалуйста.
ORM - это про доступ к данным лежащим в БД через парадигму ООП, правильно? Сделать "справочник Контрагентов" можно было в такой ситуации разве что как демонстрационный пример, как оно работает, сам смысл применения ORM в том что такие вещи делаются тривиально в том проекте где требуются, если с помощью этого ORM создание справочника это скольконибудь нетривиальная задача эту стыдобу лучше бы где-нибудь прикопать и никому не показывать, т.к. есть production-ready решения в которых это делается за час.
Но ок, допустим речь идет о Keycloak - комплексная система работы с аутентификацией/авторизацией пользователей, и вам очень захотелось взять ее к себе в проект и приделать еще что-то. Не вопрос - вы затягиваете ее к себе в проект через dependency и используете что там вам из нее надо. Там и модели построены, и описаны, и разворачивание на разные БД предусмотрено.
Допустим вы создали еще какую-то таблицу, поверх нее модель, хотите в этой модели делать связи с какими-то моделями из Keycloak (вы уже изучили документацию и хорошо понимаете что делаете) - вообще не проблема, делаете нужные вам поля у себя в модели с указаниями типов, ORM обеспечивает вам корректное раскладывание данных по моделям которы вы сами не делали.
Вы захотели еще какой-то проект затащить и взять модели из него - да не вопрос, сверились что БД общее поддерживается, добавили скрипты подготовки БД (если надо) из этого проекта, затянули его к себе через dependency. Готово. Хотите создать модель которая будет иметь часть полей из одного проекта, а часть из другого - наздоровье, продумали план обработки сущностей (как читать/как сохранять/как обновлять) и вперед, ORM позаботиться о том чтобы все распихать по таблицам как вы решили.
Или я что-то в вашей схеме не понимаю, или вам бы чуть глубже ознакомится с имеющимися решениями, почитать документацию, примеры посмотреть как это все выглядит и работает.
Есть ощущение что у вас проблема на этапе осознания чего вы хотите:
Вы хотите чтобы поля ваших моделей видели коллеги и могли указывать в своих запросах? Вам достаточно просто вести разработку в одном проекте не в блокноте, любая современная IDE вам все покаже и расскажет про уже созданные в проекте модели.
Вы хотите сделать в одном проекте РАЗНЫЕ модели навешанные на одни и те же таблицы/колонки БД? Вы хотите странного, тут так не принято ну совсем - почитайте как должен быть устроен маппинг таблиц в рамках существующих ORM.
Без тумана тайного знания в мире Java вопросы решаются следующим образом:
Осознаете что же вы на самом деле хотите
Смотрите существующие инструменты максимально покрывающие вашу потребность
Если какой-то один инструмент не нашелся - пытаетесь делить задачу на более простые и снова смотрите что есть подходящего
И вот только когда вы убедились что ничего подходящего совсем нет среди готовых инструментов вы начинаете писать велосипед
То что вы не искали подходящие инструменты видно хотябы по тому что для мапинга ваших сущностей есть много готовых инструментов, (mupstruct/Dozer/в некотором объеме даже Jackson и т.д.) но вы пошли снизу - увидели в языке вроде бы подходящий инструмент для создания своего инструмента и давай свой велосипед изобретать. Это плохой подход, не надо так - вместо того чтобы изобретать уже изобретенное, покрытое тестами и рабочее, лучше бы сделали что-то действительно новое.
И да, если пишете на языке - соблюдайте принятый Code Style, иначе ваш код читать будете только вы.
Приведенная "парадигма" очевидно никогда не была истинной - для того чтобы писать на чем-то "более низкоуровневом" и иметь от этого какой-то прирост производительности надо уметь писать на этом "более низкоуровневом" как минимум не хуже чем те кто писал "более высокоуровневые" инструменты
Может быть можно стабилизировать форму капли магнитным полем определенной конфигурации? Понятно что не для всех материалов, но там вроде сталь указана.
А чем вас не устраивает использование JPA? Хочется на уровне энтити работать - пожалуйста, хочется запрос какой-то особенный - есть native query
Все ради того чтобы экономить строчки на аннотациях?
Есть ощущение что вы пытаетесь сидеть на двух стульях - с одной стороны хочется чтобы как ORM - Repository, Entity и работа на уровне объектов, а с другой чтоб было видно конкретный sql и писать по-сути его. Если хочется именно sql то для вашей задачи у Connection (https://docs.oracle.com/en/java/javase/19/docs/api/java.sql/java/sql/Connection.html) есть метод prepareStatement(String sql, int autoGeneratedKeys), он похоже что делает то что вам нужно. Подозреваю что все развитые библиотеки-помошники в работе с JDBC вкурсе об этой возможности и скорее всего у них есть более удобный способ утилизировать эти возможности.
Мне тоже очень понравился Vue 3, круто было познакомится с script setup (правда пару раз было слишком познавательно). Возвращаться обратно не хотелось, а в проде был Vuetify 2. В общем из имевшегося тогда выбрали Element Plus. По ощущениям он больше на десктоп ориентирован, графическая часть у него послабее в плане дизайна (сугубо личное впечатление, не могу внятно объяснить), но он был достаточно стабилен чтобы использовать, имеет прилично компонентов. Вцелом как замена подошел.
Я что-то не понял, или проблему с лайками можно было починить просто написав вызов sql запроса навроде
UPDATE speakers SET likes = likes + <сколько_добавить> WHERE id = <кому>?
И, возможно, оказалось бы в итоге что вы не достаточно хорошо контролировали собственную мимику / немного по-разному предьявляли экземпляры испытуемой / что-то говорили в процессе и ваш голос немного менялся и т.п., и на самом деле суть феномена совсем в другом. Методика двойного слепого тестирования придумана не просто так.
То что вы описали это не задача, а ваше ее решение. Возможно у той исходной задачи, которую вы пытались решить генерированием миллионов объектов с несколькими стрингами внутри, есть лучшие решения на java.
Но если вы всерьез рассматривали вариант использовать UUID в качестве ключа, то получается в пакетах вендоров этот ключ может представляться строкой, а не числом. Вы не пробовали отдавать идентификатор как строчку-из-цифр, а не число?
Я правильно понимаю что у вас что-то сломалось на клиенте, и что бы это починить вы смело патчите серверную часть?
Если да то есть предположение что если сервер отдает валидные данные, а клиент на них ломается, то ошибка именно на клиенте, и именно там ее и нужно чинить.
Впринципе по статье уже понятно, что у вас критерий схожести - визуально похоже (в статье про синтаксис вспоминают постоянно), рекомендую при таком подходе наждачку и туалетную бумагу тоже вместе классифицировать - в названии и там и там "бумага", и та и та в руллонах...
Если бы вы собственную ссылку на вики прочитали внимательно, то как минимум нашли бы это:
Еще есть вот это:
Из этого можно сделать вывод что либо вы про JavaScript особо ничего не знаете, либо про Java (либо и про то и про другое).
Вы конечно не сказали после 25+ лет в какой профессии вы рекоммендации раздаете, но матчасть явно стоит подучить.
Писать такое в статье для новичков стыд и позор, прежде чем кому-то что-то советовать стоило бы ознакомиться с упоминаемыми вещами.
Подскажите пожалуйста, а вот без этого:
не заработает?
Если даже оставить за скобками претензии относительно использования модели в контроллере для представления данных ваша статья все еще плоха для новичков там, что содержит абсолютно не обязательные для воспроизведения вещи, которые зачем-то там присутствуют, и никак не комментируются.
Если не ошибаюсь основное назначение этой массивности - жесткость конструкции. Она критически важна если станок работает по шаблону, без обратной связи. Есть предположение что качественный контроль по оптическому каналу снимает необходимость столь монументальной жесткости - мясной токарь стоящий за станком бывает делает весьма точные штуки, а жесткость у него так себе
Не могли бы развернуть вашу мысль? В текущем изложении не очень понятно в чем вы видите угрозу безопасности
Из всей статьи так и не понял, основной плюс на который можно рассчитывать при использовании этого инструмента по сравнению с Postgres это отсутствие объемной документации?
А может быть вы знакомы с методикой рассчета, использованного в этом прогнозе? Мне казалось что если что-то перестали привозить совсем, то у этого чего-то цены нет (т.к. нет предложений о продаже), далее мы должны какуют-то цену (полученную в результате использования схемы "параллельный импорт") поделить на несуществующую и получить что-то в диапазоне от 1.2 до 1.4 . Как-то очень непонятно, если есть данные - поделитесь пожалуйста.