Будет поучительно для разработчиков, если окажется что они как раз понадеялись на эту "зеленую волну" и не решили вопрос проверки звуков сирен (мне кажется сделать такую проверку грамотно нетривиальная задача), и конкретно у этой пожарной машины был сломан девайс переключающий светофор (или у светофора не работал приемник для этого девайса)
Если у вас присутствует развертывание дополнительных экземпляров сервиса в ответ на повышение нагрузки на нем, вам скорее всего очень хочется чтобы старт новых экземпляров происходил максимально быстро - вот тут native image также может найти применение.
Изюминка этой СУБД в том, что не нужно выбирать между NoSQL и SQL. Она одновременно предоставляет API для работы с NoSQL и поддерживает обычные SQL-запросы.
Есть ощущение что написана какая-то глупость, выбор между NoSQL и SQL в первую очередь строиться вокруг ACID и чем из этого жертвует NoSQL ради того чтобы что-то получить. И получается что либо БД дает ACID и имеет все проблемы обеспечения этих гарантий, или нет.
Да нет же, это когда медийного блогера кормят-поят-развлекают на вечеринке, а потом он уже пилит пир-ревью - отзыв достаточно ли все было хорошо. В статье еще список застольных тем предлагают - вероятно полезный.
Слышал что сайт может использовать одновременно несколько сертификатов, и если там будет 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, там прилично написано про то как это делать если уж вы точно уверены что оно вам надо.
Хорошо хоть не Vault tec строит...
Будет поучительно для разработчиков, если окажется что они как раз понадеялись на эту "зеленую волну" и не решили вопрос проверки звуков сирен (мне кажется сделать такую проверку грамотно нетривиальная задача), и конкретно у этой пожарной машины был сломан девайс переключающий светофор (или у светофора не работал приемник для этого девайса)
Если у вас присутствует развертывание дополнительных экземпляров сервиса в ответ на повышение нагрузки на нем, вам скорее всего очень хочется чтобы старт новых экземпляров происходил максимально быстро - вот тут native image также может найти применение.
Странно когда у вроде как технологической компании на сайте логотип с выключенным JS выглядит так:
Возможно нужно что-то поправить
Есть ощущение что написана какая-то глупость, выбор между NoSQL и SQL в первую очередь строиться вокруг ACID и чем из этого жертвует NoSQL ради того чтобы что-то получить. И получается что либо БД дает ACID и имеет все проблемы обеспечения этих гарантий, или нет.
мне кажется что дословно "дизайн нарезанный по фичам" (если мы конечно считаем что 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, там прилично написано про то как это делать если уж вы точно уверены что оно вам надо.