Интересно бы увидеть как постгрес может помечать слова которые послужили триггером для нахождения, и что делать с мультиязычными данными? Токенизировать в одну колонку все языки, или создавать по колонке на язык?
Интересно было бы посмотреть на дальнейшую интеграцию с react query, в последних версиях это можно сделать на верхнем уровне, когда определяется QueryClient.
Ну над одиночными методами чтения такие аннотации может и не нужны пока у вас одна дб, а как только вы хотите ходить в read replic для всех readOnly транзакций то без неё уже никак. Приходится имплементировать routing data source и использовать этот флаг для выбора нужного.
С точки зрения трудового законодательства многих стран понятия оффера не существует.
Хотя и в России насколько я знаю существует предварительный трудовой договор, ну или как сказали ниже можно просто подписать основной с отложенной датой.
Но во многих странах существуют аналоги, что-то вроде предварительного трудового договора и просить надо именно его, прежде чем увольняться.
Франция - Promesse d'embauche - Обещание о найме. Германия - Vorvertrag - Предварительный договор. Италия - Lettera di impegno - Письмо об обязательстве. Испания - Precontrato laboral - Предварительный трудовой договор. Швейцария - Zusicherung der Anstellung - Обещание трудоустройства. Япония - 内定通知書 (Naitei Tsuuchi-sho) - Уведомление о предварительном трудоустройстве.
У React Query гораздо больше вещей уже готовы в добавок они сделаны с нормальным api. Хотя на первый взгляд они похоже особенно в синтетических примерах где качают пару объектов с fakejson.com. Но когда речь заходит о минимальной кастомизации RTK Query просто деревянный, обращение к кэшу у RQ гораздо проще, работа с сокетами в RTK делается во много строк кода с непонятными подписками в коллбэках конфигурации. Ленивая загрузка когда у тебя в ответе приходит параметр для следующей страницы практически невозможна, он хранит это как отдельные записи кэша а не связный список. И для всего этого приходится писать огромное количество кода. Причём для ленивой загрузке, на гитхабе, просят сделать api как у RQ но насколько я понял подвижек нет особых.
Смотря на такие статьи про column tetris всегда возникает вопрос, а что мешает постгрес самому складывать данные самым оптимальным образом? Он ведь даже может запоминать порядок полей при котором была создана таблица чтобы скрывать это от пользователя, но хранить это в оптимальной последовательности. Даже boolean он мог бы складывать в smallint и проводить такие трансформации под капотом.
Они могут легально ззанять только если жилье не является вашем основным местом проживания.
Интересно бы увидеть как постгрес может помечать слова которые послужили триггером для нахождения, и что делать с мультиязычными данными? Токенизировать в одну колонку все языки, или создавать по колонке на язык?
Интересно было бы посмотреть на дальнейшую интеграцию с react query, в последних версиях это можно сделать на верхнем уровне, когда определяется QueryClient.
Ну над одиночными методами чтения такие аннотации может и не нужны пока у вас одна дб, а как только вы хотите ходить в read replic для всех readOnly транзакций то без неё уже никак. Приходится имплементировать routing data source и использовать этот флаг для выбора нужного.
Может пропустил, но не сказали о главной особенности. Если приложение не использует java модули то все наследники должны быть в одном пакете.
Ну насколько я понисаю в 19 реакте с новым коипилятором всё к этому и идёт. Будут после компиляции стараться оборачивать всё.
Может просто потому что это удобно, и у реакта есть инструменты для этого.
Вы про Россию, но я отвечал на это заявление:
Хотя и в России насколько я знаю существует предварительный трудовой договор, ну или как сказали ниже можно просто подписать основной с отложенной датой.
И подорвали бы его вместе с Журналистом-патриотом.
Но во многих странах существуют аналоги, что-то вроде предварительного трудового договора и просить надо именно его, прежде чем увольняться.
Франция - Promesse d'embauche - Обещание о найме.
Германия - Vorvertrag - Предварительный договор.
Италия - Lettera di impegno - Письмо об обязательстве.
Испания - Precontrato laboral - Предварительный трудовой договор.
Швейцария - Zusicherung der Anstellung - Обещание трудоустройства.
Япония - 内定通知書 (Naitei Tsuuchi-sho) - Уведомление о предварительном трудоустройстве.
У React Query гораздо больше вещей уже готовы в добавок они сделаны с нормальным api. Хотя на первый взгляд они похоже особенно в синтетических примерах где качают пару объектов с fakejson.com. Но когда речь заходит о минимальной кастомизации RTK Query просто деревянный, обращение к кэшу у RQ гораздо проще, работа с сокетами в RTK делается во много строк кода с непонятными подписками в коллбэках конфигурации. Ленивая загрузка когда у тебя в ответе приходит параметр для следующей страницы практически невозможна, он хранит это как отдельные записи кэша а не связный список. И для всего этого приходится писать огромное количество кода. Причём для ленивой загрузке, на гитхабе, просят сделать api как у RQ но насколько я понял подвижек нет особых.
Ну по усолчанию он вообще отключен staleTime равно 0 насколько я помню. Так что если вам он не нужен, просто не устанавливайте его.
Просто в настройках профиля ребёнка в который вы заходите со своим google паролем есть такая функция:
Вы просто разрешаете нормальные видео и каналы. Все остальные будут недоступны.
А какая проблема с youtube kids? Просто разрешаешь некоторые каналы или отдельные видео, и всё. Остальные будут скрыты.
Здравствуйте, а покупку зарубежной картой не добавили?
Смотря на такие статьи про column tetris всегда возникает вопрос, а что мешает постгрес самому складывать данные самым оптимальным образом? Он ведь даже может запоминать порядок полей при котором была создана таблица чтобы скрывать это от пользователя, но хранить это в оптимальной последовательности. Даже boolean он мог бы складывать в smallint и проводить такие трансформации под капотом.
Господи, на что люди готовы пойти лишь бы не использовать jooq. Даже на изучение jpa спецификации и всех неявных подводных камней хибера.
А вообще если время тратить некуда то лучше уж изучить sql и спокойно писать на jooq.
В чём проблема просто физически вывести из строя микрофон? А для разговора пользоваться bluetooth гарнитурой и отключать её когда не используется.
Ну может человек просто конкурентов создавать не хочет и желает оставаться единственным специалистом по криптографии.
Звучит как начало анекдота