Да нет же, это когда медийного блогера кормят-поят-развлекают на вечеринке, а потом он уже пилит пир-ревью - отзыв достаточно ли все было хорошо. В статье еще список застольных тем предлагают - вероятно полезный.
Слышал что сайт может использовать одновременно несколько сертификатов, и если там будет 2, один отчесетвенный второй нет, и второй отзовут, то при наличии добавленных отечественных УЦ сайт останется доступным для пользователя
Лично мое мнение что делать некачественно - непрофессионально, не важно за какие деньги, т.к. ты же за них согласился работать. Если деньги тебя не устраивают - не соглашаешься, если согласился - делаешь насколько можешь хорошо
выведем список всех выкупленных билетов на заданную дату
scheduled_departure > "2017-07-18"
Подскажите пожалуйста, а подобная конструкция не отфильтрует ли билет, купленный в 2017-07-18T00:00:00.0(в таймзоне применяемой в рамках приведенного запроса) ?
В path нельзя положить UUID, т.к. данные в ltree не могут содержать дефис
Вообще говоря дефисы в UUID для человекочитаемости, если их убрать уникальность идентификатора не пострадает. Поэтому строго говоря утверждение неверно - положить можно, но нужно представление UUID без дефисов.
Василиса может у себя заложится на простой ключ для работы с контрагентом
Т.е. Василиса пилит у себя функционал по еще не существующему связанному справочнику, договоренностей никаких, она просто решила что почему бы тому вот будущему справочнику не быть таким? Это проблема организации рабочего процесса и стандартизация в части ключей ничего не даст - у связанного справочника может оказаться такая логика функционирования что несовпадающий ключ это будут мелочи, и чтож теперь, делать стандарт на функционирование всех на свете справочников?
Если же мы говорим что справочник таки уже существует - мы просто берем его к себе в проект и смотрим какой там ключ.
Ситуацию можно образно описать так: вы много работали с автомобильными заводами, вы пришли на завод заводов и пытаетесь доказать что вот этот вот станок должен обязательно выпускать колеса, иначе без этого куча времени уходит на всякую фигню, хотя и так же понятно что колесо тут подойдет. Но люди которые много лет проектировали этот завод заводов не просто так сделали именно так, и вместо того чтобы доказывать необходимость стандартизации лучше бы почитать насчет того что и как вообще завод заводов делает, возможно настройка его на выпуск колес настолько тривиальная задача что об этом как о задаче даже говорить не принято.
Когда я смотрю литературу по паттернам (и антипаттернам) я понимаю что это рецепты организации кода, часто с абстрактными примерами
Большинство конкретных примеров вы найдете либо в рабочих проектах коллег, либо в статьях/выступлениях ребят кто любит рассказывать что у них на проектах случалось и как они это решали. Из авторов по JPA/Hibernate могу рекомендовать Vlad Mihalcea и Thorben Janssen
Это именно у Hibernate или у JPA тоже есть такой механизм
Судя по вопросу вы ни туда ни туда не смотрели, обратитесь к @Id
Я указал на Hibernate просто как на референсную реализацию, в его документации достаточно хорошо освещены все JPA возможности и его частные доработки (легко понять что к чему относиться по пакетам)
У Cправочника ролей есть getUserRoleByName() но перед этим нужно сделать setCurrenUser(UserID)
Вы не шутите? А эту вот информацию вы в сопроводительной записке к вашей реализации напишете?
В параллельной ветке увидел у вас такое:
class MyPaymentOrder extends PaymentOrder
Вы похоже даже не понимаете насколько гиблое дело наследование в моделях. Нет, если вы живете по ватерфоллу, вы можете себе позволить спроектировать очень красивую, аккуратную, "эффективно немногословную" схему моделей. Но почти любое изменение в моделях будет аукаться у вас по всей выстроенной системе типов. Так не надо делать никогда, если только вы на 100% не уверены что абсолютно точно понимаете почему вы именно так поступаете. Как общий паттерн проектирования это абсолютно негодно.
И даже если вы хотите наследование - загляните в документацию Hibernate, там прилично написано про то как это делать если уж вы точно уверены что оно вам надо.
Вот тут самое интересное начинается, если в "моделях" нет стандарта на уникальный ключ записей (guid или чтото подобное) , с типами Вы начнете искать "что БД общее поддерживается". А что может быть ключом для справочника пользовалей - да кто что придумает . Ктото ID с типом Integer , Кто то AccountID типа String, а кторо ФИО в трех полях и будет ждать когда тезка придет. И да кодом Вы решите и в Вашей IDE наверняка будет генератор классов для ORM.
Вы должно быть шутите. С чего вдруг меня вообще должно волновать какой там первичный ключ в чьей-то там модели? Я саму модель пишу в поле, а не ее ключ, ORM сам делает все что нужно там с этим ключом делать в той модели, хоть UUID там хоть sequence какой.
Вендор 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, иначе ваш код читать будете только вы.
производительность - выбирай более низкоуровневый язык
Приведенная "парадигма" очевидно никогда не была истинной - для того чтобы писать на чем-то "более низкоуровневом" и иметь от этого какой-то прирост производительности надо уметь писать на этом "более низкоуровневом" как минимум не хуже чем те кто писал "более высокоуровневые" инструменты
мне кажется что дословно "дизайн нарезанный по фичам" (если мы конечно считаем что feature можно переводить как фича)
Да нет же, это когда медийного блогера кормят-поят-развлекают на вечеринке, а потом он уже пилит пир-ревью - отзыв достаточно ли все было хорошо. В статье еще список застольных тем предлагают - вероятно полезный.
Вроде бы плашки "перевод" нет, а написано как-то странно, наверное дело не закрыто, а было предварительное слушание в закрытом режиме?
https://docs.cntd.ru/document/1200105673
Этот гост по вашей логике получается на то чего нельзя продавать, вроде как
https://docs.cntd.ru/document/1200105673
Подскажите пожалуйста, а этот гост зачем?
Wat?
Правильный ответ что-то в духе "Вежливое обращение к коллеге писавшему класс с просьбой сделать внутренние поля написанного класса приватными"?
А нельзя чем-нибудь плавким заткнуть сопло, вакуумировать, а после поджига оно уже само расплавится и вытечет?
Слышал что сайт может использовать одновременно несколько сертификатов, и если там будет 2, один отчесетвенный второй нет, и второй отзовут, то при наличии добавленных отечественных УЦ сайт останется доступным для пользователя
Лично мое мнение что делать некачественно - непрофессионально, не важно за какие деньги, т.к. ты же за них согласился работать. Если деньги тебя не устраивают - не соглашаешься, если согласился - делаешь насколько можешь хорошо
Подскажите пожалуйста, а подобная конструкция не отфильтрует ли билет, купленный в 2017-07-18T00:00:00.0(в таймзоне применяемой в рамках приведенного запроса) ?
Вообще говоря дефисы в UUID для человекочитаемости, если их убрать уникальность идентификатора не пострадает. Поэтому строго говоря утверждение неверно - положить можно, но нужно представление UUID без дефисов.
А можете всеже пояснить, что не так с OneToOne (если я правильно понял о чем речь)?
вот бы сравнить предложенную реализацию с чем-то не требующим рекурсивных запросов, например: https://en.wikipedia.org/wiki/Nested_set_model
Т.е. Василиса пилит у себя функционал по еще не существующему связанному справочнику, договоренностей никаких, она просто решила что почему бы тому вот будущему справочнику не быть таким? Это проблема организации рабочего процесса и стандартизация в части ключей ничего не даст - у связанного справочника может оказаться такая логика функционирования что несовпадающий ключ это будут мелочи, и чтож теперь, делать стандарт на функционирование всех на свете справочников?
Если же мы говорим что справочник таки уже существует - мы просто берем его к себе в проект и смотрим какой там ключ.
Ситуацию можно образно описать так: вы много работали с автомобильными заводами, вы пришли на завод заводов и пытаетесь доказать что вот этот вот станок должен обязательно выпускать колеса, иначе без этого куча времени уходит на всякую фигню, хотя и так же понятно что колесо тут подойдет. Но люди которые много лет проектировали этот завод заводов не просто так сделали именно так, и вместо того чтобы доказывать необходимость стандартизации лучше бы почитать насчет того что и как вообще завод заводов делает, возможно настройка его на выпуск колес настолько тривиальная задача что об этом как о задаче даже говорить не принято.
Большинство конкретных примеров вы найдете либо в рабочих проектах коллег, либо в статьях/выступлениях ребят кто любит рассказывать что у них на проектах случалось и как они это решали. Из авторов по JPA/Hibernate могу рекомендовать Vlad Mihalcea и Thorben Janssen
Судя по вопросу вы ни туда ни туда не смотрели, обратитесь к @Id
Я указал на Hibernate просто как на референсную реализацию, в его документации достаточно хорошо освещены все JPA возможности и его частные доработки (легко понять что к чему относиться по пакетам)
Вы не шутите? А эту вот информацию вы в сопроводительной записке к вашей реализации напишете?
В параллельной ветке увидел у вас такое:
Вы похоже даже не понимаете насколько гиблое дело наследование в моделях. Нет, если вы живете по ватерфоллу, вы можете себе позволить спроектировать очень красивую, аккуратную, "эффективно немногословную" схему моделей. Но почти любое изменение в моделях будет аукаться у вас по всей выстроенной системе типов. Так не надо делать никогда, если только вы на 100% не уверены что абсолютно точно понимаете почему вы именно так поступаете. Как общий паттерн проектирования это абсолютно негодно.
И даже если вы хотите наследование - загляните в документацию Hibernate, там прилично написано про то как это делать если уж вы точно уверены что оно вам надо.
Вы должно быть шутите. С чего вдруг меня вообще должно волновать какой там первичный ключ в чьей-то там модели? Я саму модель пишу в поле, а не ее ключ, ORM сам делает все что нужно там с этим ключом делать в той модели, хоть UUID там хоть sequence какой.
Истинно глаголю вам, откройте документацию тогоже Hibernate, посмотрите примеры.
ORM - это про доступ к данным лежащим в БД через парадигму ООП, правильно? Сделать "справочник Контрагентов" можно было в такой ситуации разве что как демонстрационный пример, как оно работает, сам смысл применения ORM в том что такие вещи делаются тривиально в том проекте где требуются, если с помощью этого ORM создание справочника это скольконибудь нетривиальная задача эту стыдобу лучше бы где-нибудь прикопать и никому не показывать, т.к. есть production-ready решения в которых это делается за час.
Но ок, допустим речь идет о Keycloak - комплексная система работы с аутентификацией/авторизацией пользователей, и вам очень захотелось взять ее к себе в проект и приделать еще что-то. Не вопрос - вы затягиваете ее к себе в проект через dependency и используете что там вам из нее надо. Там и модели построены, и описаны, и разворачивание на разные БД предусмотрено.
Допустим вы создали еще какую-то таблицу, поверх нее модель, хотите в этой модели делать связи с какими-то моделями из Keycloak (вы уже изучили документацию и хорошо понимаете что делаете) - вообще не проблема, делаете нужные вам поля у себя в модели с указаниями типов, ORM обеспечивает вам корректное раскладывание данных по моделям которы вы сами не делали.
Вы захотели еще какой-то проект затащить и взять модели из него - да не вопрос, сверились что БД общее поддерживается, добавили скрипты подготовки БД (если надо) из этого проекта, затянули его к себе через dependency. Готово. Хотите создать модель которая будет иметь часть полей из одного проекта, а часть из другого - наздоровье, продумали план обработки сущностей (как читать/как сохранять/как обновлять) и вперед, ORM позаботиться о том чтобы все распихать по таблицам как вы решили.
Или я что-то в вашей схеме не понимаю, или вам бы чуть глубже ознакомится с имеющимися решениями, почитать документацию, примеры посмотреть как это все выглядит и работает.
Есть ощущение что у вас проблема на этапе осознания чего вы хотите:
Вы хотите чтобы поля ваших моделей видели коллеги и могли указывать в своих запросах? Вам достаточно просто вести разработку в одном проекте не в блокноте, любая современная IDE вам все покаже и расскажет про уже созданные в проекте модели.
Вы хотите сделать в одном проекте РАЗНЫЕ модели навешанные на одни и те же таблицы/колонки БД? Вы хотите странного, тут так не принято ну совсем - почитайте как должен быть устроен маппинг таблиц в рамках существующих ORM.
Без тумана тайного знания в мире Java вопросы решаются следующим образом:
Осознаете что же вы на самом деле хотите
Смотрите существующие инструменты максимально покрывающие вашу потребность
Если какой-то один инструмент не нашелся - пытаетесь делить задачу на более простые и снова смотрите что есть подходящего
И вот только когда вы убедились что ничего подходящего совсем нет среди готовых инструментов вы начинаете писать велосипед
То что вы не искали подходящие инструменты видно хотябы по тому что для мапинга ваших сущностей есть много готовых инструментов, (mupstruct/Dozer/в некотором объеме даже Jackson и т.д.) но вы пошли снизу - увидели в языке вроде бы подходящий инструмент для создания своего инструмента и давай свой велосипед изобретать. Это плохой подход, не надо так - вместо того чтобы изобретать уже изобретенное, покрытое тестами и рабочее, лучше бы сделали что-то действительно новое.
И да, если пишете на языке - соблюдайте принятый Code Style, иначе ваш код читать будете только вы.
Приведенная "парадигма" очевидно никогда не была истинной - для того чтобы писать на чем-то "более низкоуровневом" и иметь от этого какой-то прирост производительности надо уметь писать на этом "более низкоуровневом" как минимум не хуже чем те кто писал "более высокоуровневые" инструменты