Я - человек простой: вижу видосик на letsCode - ставлю лайк) Снимаю шляпу перед автором, всё чётко, без лишней воды, и практично. Сочетание затраченное время/полученное понимание - самое лучшее среди всех ютьюб видосиков что я смотрел❤🔥
Андрей как всегда на высоте:) P.S.: забавно видеть, как крутые разрабы так же программируют методом "запустили - чёт упало - я всё понял - заработало", но делают это они быстро:)))
Ну опытные разрабы тоже ошибаются. Особенно на технологиях, которые ещё не использовали мильён раз в проектах. Какие-то простые вещи бывает пишу с первого раза и сразу удачно, но это обычно что-то до абсолютно понятное. Опытные водители тоже всех ямок объехать не могут, а те, что есть объезжают быстро и с тряской)
посмотрел 3 видео о webFlux. Очень крутые и информативные видео!Ещё много видео на канале , которые очень интересны для меня. Буду смотреть! Подписался!
17:03 Насколько помню, документация Postgresql рекомендует для VARCHAR размер не указывать для performance. P.S. www.postgresql.org/docs/11/datatype-character.html Tip There is no performance difference among these three types, apart from increased storage space when using the blank-padded type, and a few extra CPU cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, there is no such advantage in PostgreSQL; in fact character(n) is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead. Хотя, перечитал, это скорее про character(n), чем varchar(n)
Хотя, перечитал, это скорее про character(n), чем varchar(n): www.postgresql.org/docs/11/datatype-character.html Tip There is no performance difference among these three types, apart from increased storage space when using the blank-padded type, and a few extra CPU cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, there is no such advantage in PostgreSQL; in fact character(n) is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead.
зачем делать конструкторы у сервисов, когда у ломбока есть наташка "RequiredArgsConstructor" которая все final переменные пихает в конструктор? спасибо за видео, было интересно!
А что будет если с WebFlux использовать обычный репозиторий не реактивный, по идее все равно каждый запрос к БД будет обрабатываться, в отдельно потоке, и приложение будет реактивным, только разница, в том, что запросы к БД будут блокирующими, но работать то будет нормально так?
ну, насколько я понимаю, лучше всегда создавать все через миграцию, особенно если разработка идет в несколько лиц. Лучше уж сразу так делать. Кстати, почему не liquibase?
@@letsCodeDru Кстати недавно выбирал между ними. Интересно Ваше мнение. Мои краткие выводы были такие: For DB migrations was chosen Liquibase tool between Liquibase and Flyway (both represented in Spring starter tool). Reason: Liquibase has rollback in free version. Еще я не включал migration tool в pom.xml: Liquibase is not incorporated to Spring project itself (not in pom.xml) because in that case it run migrations on app start which is bad practice as I think.
лол, так эта хрень вообще не ORM. Я понимаю, более эффективная работа с бд. А если у меня миллиард one/many-to-many связей в бд, я могу тут что-то прикрутить на уровне OneToMany аннотаций, чтобы все автоматом прилетало? Или (возможно пока) придется страдать написанием нативного sql над методами репозитория, как только появляется какая-то из таких связей?
Не надо бояться, глупо выглядит тот, кто не понял и не спросил. Реактивный драйвер позволяет более эффективно использовать подключение к бд. Быстрее оно работать не станет, но под большими нагрузками меньше шансов получить отвалившихся клиентов. Более разумное расходование ресурсов как бонус. Т.е. все те же плюсы, что и в реактивном вэбе
@@letsCodeDruНемного добавлю: JDBC априори технология на блокировках, следовательно никак не получиться использовать в реактивнхы приложениях. Ранее спринг умел только реактивные Mongo репозитории (так как реактивный драйвер был), были попытки написать какие-то реактивные дравера для RDBMS, но это не было стандартом! R2DBC Во всяком случае внятная штука, идущая к стандарту (r2dbc.io/). Т.е. Кратко: R2DBC это когда хочеться WebFlux и Reactor в приложении но так же хочеться RDBMS.
Я - человек простой: вижу видосик на letsCode - ставлю лайк)
Снимаю шляпу перед автором, всё чётко, без лишней воды, и практично.
Сочетание затраченное время/полученное понимание - самое лучшее среди всех ютьюб видосиков что я смотрел❤🔥
Дай бог тебе здоровья, добрый человек!
Спасибо!) интересно что вы думаете про Liquibase vs Flyway
Коротко и ясно, то что надо! Благодарность автору за видео!
классно, всё понятно, теперь я умею реактивить в яве. Благодарность автору от души
Жирный лайк. Запросы на апи через консоль хрома это конечно хардкор)
Андрей как всегда на высоте:)
P.S.: забавно видеть, как крутые разрабы так же программируют методом "запустили - чёт упало - я всё понял - заработало", но делают это они быстро:)))
Магия монтажа 😁
Ну нет. Тут я почти не вырезал лишнего. Пору 20-30 секундный мычание только.
Ну опытные разрабы тоже ошибаются. Особенно на технологиях, которые ещё не использовали мильён раз в проектах. Какие-то простые вещи бывает пишу с первого раза и сразу удачно, но это обычно что-то до абсолютно понятное. Опытные водители тоже всех ямок объехать не могут, а те, что есть объезжают быстро и с тряской)
@@letsCodeDru что тут крутого, это реально доступный и понятный язык и аналогии, которые приводишь, спасибо Андрей
Спасибо за видео.Коммент в поддержку!
посмотрел 3 видео о webFlux. Очень крутые и информативные видео!Ещё много видео на канале , которые очень интересны для меня. Буду смотреть! Подписался!
Как раз изучаю R2DBC, видео в тему! Я рад! Ты самый лучший!
Спасибо за видео, оч интересно!
Наконец-то я понял больше чем не понял. Хорошие заметки, очень полезно
Спасибо за крутой видосик) Мотивация прёт, уже вторую неделю пилю свой пет-проект)
Клас, круто, и все ставим лайк.
захожу каждые 3 дня проверять когда ждать новую серию
Спасибо за твои видео
Спасибо большое!
Спасибо огромное - материал бомба!
Спасибо огромное!)) Очень интересное и полезное видео))
Крутой канал, круто автор!!!
Балдежный туториал
Отличное видео! Хотелось бы еще видос с разбором правильного построения тестов под webFlux и вообще реактивного стиля...
По поводу ОРМ, недавно вышел реактивный JOOQ
вырос на твоих видосах
Прикольно, но хотелось бы еще глянуть на функциональный подход) В любом случае спасибо за годноту)
все чотко по полкам!
Крутой видос!
Спаисбо, прет норм)
17:03 Насколько помню, документация Postgresql рекомендует для VARCHAR размер не указывать для performance.
P.S. www.postgresql.org/docs/11/datatype-character.html
Tip
There is no performance difference among these three types, apart from increased storage space when using the blank-padded type, and a few extra CPU cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, there is no such advantage in PostgreSQL; in fact character(n) is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead.
Хотя, перечитал, это скорее про character(n), чем varchar(n)
Хотя, перечитал, это скорее про character(n), чем varchar(n):
www.postgresql.org/docs/11/datatype-character.html
Tip
There is no performance difference among these three types, apart from increased storage space when using the blank-padded type, and a few extra CPU cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, there is no such advantage in PostgreSQL; in fact character(n) is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead.
На варчар тоже никто не ставит;)
Крутое видео, спасибо! Что думаешь о сравнении Flyway и Liquibase ?!
Есть ReactiveMongo от спринга.
осознанный комментарий для продвижения дичи
как раз сейчас перехожу на реактивщину, как закрепление прочтенного в доках - гуд ) больше дичи!) спасибо
А вы работаете спринг разработчиком?
Сейчас уже(Spring boot 2.6.3) с такими зависимостями добавляет:
implementation 'org.springframework:spring-jdbc'
Почаще про какие-либо подводные камни сообщай) конечно набитые шишки дольше помнятся, но лучше их поменьше)
зачем делать конструкторы у сервисов, когда у ломбока есть наташка "RequiredArgsConstructor" которая все final переменные пихает в конструктор?
спасибо за видео, было интересно!
А чего йамл свойства не используешь? Или ностальгия по пропертям?
в идеи же можноspring init кликать
Ох, печально за 10 дней и 500 лайков нет, а плейлист то супер интересный мог бы выйти.
Вот че-то да. Больше просили :(
@@letsCodeDru максимальные просмотры на нубовых темах, а до реактивных соединений с БД даже не у всех сеньоров руки дошли, еще доберутся)
Что может послужить причиной, для того чтобы переписать jdbc на r2dbc?
Кто-нибудь продакшн уже делал с R2DBC? Можно уже использовать?
можно
Даёшь ReactiveMongoRepository ? ), а еще удобно делать запросы через файл HTTP Request в Idea
Почему для отправки запросов не используете Postman? Так ведь гораздо удобнее
Андрей, привет, спасибо за видео! Только почему не используешь аннотацию @RequiredArgsConstructor ? Удобнее ведь :)
Использую, когда уместна
@@letsCodeDru Она очень уместна при инжекте бинов, вместо конструктора с автовайром)
А что будет если с WebFlux использовать обычный репозиторий не реактивный, по идее все равно каждый запрос к БД будет обрабатываться, в отдельно потоке, и приложение будет реактивным, только разница, в том, что запросы к БД будут блокирующими, но работать то будет нормально так?
скачал проект. но почему то не происходит сохранения в базу. ошибки никакой не выдает. а в базе пусто.
Андрей, как обычно круто
Но почему ты выбрал подход через контроллеры, а не через хэндлеры?
Спасибо
Меньше букаф писать. Читать привычней. Переезжать с готовым кодом проще.
Начал смотеть думая о том, что о сейчас расскажут про github.com/davidmoten/rxjava2-jdbc
Ждем следующих серий
Насколько WebFlux актуален сегодня при том что завезли виртуальные потоки?
А как же Linux?)))
Спасибо за видос, ждем следующую серию)
Ноут сломался, перебивают на десктопе
Цитата люблю я так писать код :)
Возможно удобнее было бы автору создавать базу тоже на лету, shell скриптом например и поднимать db в докере? А за видос спасибо! Лайк!
не совсем понял суть WebFlux и R2DBC в данном примере, если в конце пришлось обновить страницу, чтобы записи обновились )
хелп , пишу "id bigserial primary key " в файле V1__Initial_db.sql, а он пишет что "unable to resolve object type bigserial"
Здравствуйте! Спасибо за видео!
Хотел спросить, какой Linux distribution Вы используете?
Тут винда((
😁
нафик он нужен на десктопе?
А github.com/hibernate/hibernate-rx разве не ORM с поддержкой реактивности ?
This project is still at an experimental stage of development. Со страницы по ссылке.
ну, насколько я понимаю, лучше всегда создавать все через миграцию, особенно если разработка идет в несколько лиц. Лучше уж сразу так делать.
Кстати, почему не liquibase?
Люблю sql. Привык к flyway
@@letsCodeDru Кстати недавно выбирал между ними. Интересно Ваше мнение. Мои краткие выводы были такие:
For DB migrations was chosen Liquibase tool between Liquibase and Flyway (both represented in Spring starter tool).
Reason: Liquibase has rollback in free version.
Еще я не включал migration tool в pom.xml:
Liquibase is not incorporated to Spring project itself (not in pom.xml) because in that case it run migrations on app start which is bad practice as I think.
возможно глупый вопрос, но почему не генерируете проект сразу в idea?
Хз. Привычка, походу
если много компонентов нужно автовайрить в классе вы их тоже в конструктор ставите?
Да, но у нас есть ломбок. @RequiredArgsConstructor сделает это за нас
А будет ли webflux с каким-нибудь js фреймворком, типо react
бери простой webflux и простой jhipster с React-ом
)
Взять тот же FE сарафан и мигрировать бэкэнд на флюкс.
что угодно только не реакт,да и походу он решил через мусташ делать
Блин, ребят, давайте поднажмем до 500. Месяц уже продолжения нет
Первый
лол, так эта хрень вообще не ORM. Я понимаю, более эффективная работа с бд. А если у меня миллиард one/many-to-many связей в бд, я могу тут что-то прикрутить на уровне OneToMany аннотаций, чтобы все автоматом прилетало? Или (возможно пока) придется страдать написанием нативного sql над методами репозитория, как только появляется какая-то из таких связей?
С монгой можно было, там есть реактив
Не люблю монгу)
я так и не понял, тот же контроллер, тот же сервис и репо, а где реактивщина? кроме моно и флакс ниче не поменялось
@letsCode Андрей к ссылке на гит репо приклеилось словоSpring
а вот рабочая ссылка
github.com/drucoder/catalizator/tree/R2DBC_flyway
Дожмите 500, камоооооооон
Завозим фуру лайков
какая то не понятная дичь....Надо пересмотреть и ознакомиться с р2дбс
Ужасное видео! Опять бекенд не на NodeJS. Лайк) Кстати, я Flyway пользуюсь, мне никаких доп зависимостей не нужно ;/
С чем используешь? С spring data? Jpa? Они напару тянут jdbc в транзитивных зависимостях. Ессно тогда не надо отдельно указывать
@@letsCodeDru а ну да, spring-data-jpa :) буду знать) это когда начал изучать спринг сразу с спринг бута )00
Боюсь показаться тупым, но хотя бы два слова, в чём прикол от R2DBC?!
Не надо бояться, глупо выглядит тот, кто не понял и не спросил.
Реактивный драйвер позволяет более эффективно использовать подключение к бд. Быстрее оно работать не станет, но под большими нагрузками меньше шансов получить отвалившихся клиентов. Более разумное расходование ресурсов как бонус. Т.е. все те же плюсы, что и в реактивном вэбе
@@letsCodeDruНемного добавлю: JDBC априори технология на блокировках, следовательно никак не получиться использовать в реактивнхы приложениях. Ранее спринг умел только реактивные Mongo репозитории (так как реактивный драйвер был), были попытки написать какие-то реактивные дравера для RDBMS, но это не было стандартом! R2DBC Во всяком случае внятная штука, идущая к стандарту (r2dbc.io/). Т.е. Кратко: R2DBC это когда хочеться WebFlux и Reactor в приложении но так же хочеться RDBMS.
Что произошло на 03:38 ? дизлайк ловите за такое!)
откуда этот код?
Спасибо за видео!