Мне кажется стоит поменять sql запросы чтобы он выдавал только один уникальный ID статьи. А то такой ответ смотрится немного странно: https://habr.com/ru/articles/757278 https://habr.com/ru/articles/757278 https://habr.com/ru/articles/757278 https://habr.com/ru/articles/757278 https://habr.com/ru/articles/757278 (5 rows)
Интересно бы увидеть как постгрес может помечать слова которые послужили триггером для нахождения, и что делать с мультиязычными данными? Токенизировать в одну колонку все языки, или создавать по колонке на язык?
Интересно было бы посмотреть на дальнейшую интеграцию с 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 и проводить такие трансформации под капотом.
1 Только в win
Больше, там помоему по 4Mb на системный поток
Мне кажется стоит поменять sql запросы чтобы он выдавал только один уникальный ID статьи. А то такой ответ смотрится немного странно:
https://habr.com/ru/articles/757278https://habr.com/ru/articles/757278
https://habr.com/ru/articles/757278
https://habr.com/ru/articles/757278
https://habr.com/ru/articles/757278
(5 rows)
Они могут легально ззанять только если жилье не является вашем основным местом проживания.
Интересно бы увидеть как постгрес может помечать слова которые послужили триггером для нахождения, и что делать с мультиязычными данными? Токенизировать в одну колонку все языки, или создавать по колонке на язык?
Интересно было бы посмотреть на дальнейшую интеграцию с 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.