Комментарии 16
По моему забыли добавить такое предупреждение:
Уважаемые разработчики! Используйте данные примеры, только для изучения принципов работы со Stream API. На реальных проектах использовать эти примеры для фильтрации данных из БД категорически не нужно.
Спасибо за комментарий. Добавил в статью: "данная статья написана исключительно в целях демонстрации основ работы Stream API и структура проекта, используемая в ней для примера, не подходит для применения на реальных проектах".
Мне кажется, стоит явно указать что не так с этими примерами. Почему нельзя использовать на проде, в чем узкие места, какие альтернативы есть.
Это все поможет понять методы применимости и то, в какую сторону можно копать дальше.
На мой взгляд, просто красного флажка "так делать нельзя! ни за что никогда!" недостаточно. Да какого флажка! Нужен транспарант с аршинными буквами!
Кстати, у вас я такого не заметил. Ну не считать же фразу про "структура проекта не подходит для использования на проде" достаточным объяснением? Структуру нельзя, а запросы — можно? ;-)
Мы же обсуждаем статью "для начинающих"? Мне кажется, одной фразы недостаточно.
Во-первых, ее можно просто пропустить. То есть лучше сказать об этом дважды: при первом использовании, и в отдельном разделе.
Во-вторых, важный вопрос "а как делать правильно"? Как раз для отдельного раздела — хотя бы просто отсылки на способы, чтобы заинтересованный знал куда копать дальше.
В-третьих, разобрать ленивость стримов: что такое, когда работает, насколько эффективно, почему не работает тут. Лично я не могу сказать, что без подготовки готов ответить на все эти вопросы.
Ну и в-последних — а когда данных становится много? Хотя бы примерные оценки по числу сущностей, чтобы решать проблему не на проде код-ревью.
Спасибо за комментарий. Сами запросы - это демонстрация основ работы Stream API. :-)
Было бы интересней, если бы к каждому стриму вы приложили SQL, который улетает в базу. Что-то мне подсказывает, там есть на что посмотреть и над чем задуматься )
И отредактируйте заголовок примера 9.
Так же нельзя писать в проде. Никогда нельзя.
Даже для статьи можно подобрать примеры которые можно использовать в продакшене. Джейсон прилетевший из внешней системы. Вызов апишки которая не позволят нужную фильтрацию (поискать у кого такие есть чтобы еще реальнее было). Валидаторы какие-нибудь. Потоковая обработка чего-то из Кафки. Куча реальных примеров.
Можете раскрыть мысль, почему именно нельзя?
Потому что тащить из БД 100500 записей, чтобы, например, найти в них всего одну, у которой какой-то атрибут равен true, - идиотизм и работа на отопление помещения датацентра.
Вот! Наглядный пример, что такого раздела в самой статье не хватает. MiSta1984 может стоит улучшить статью?
Отвечаю по теме: Repository.findAll() загружает из базы все данные, а потом мы с ними что-то делаем.
На проде обычно миллионы записей, и на каждый запрос получать их все чтобы показать десяток — это ужас-ужас. Дикая нагрузка на БД, на сборщик мусора и сам сервис.
Немного режет глаза отсутствие static в константе и сравнение equals не «от константы», но в целом хорошо. Побольше бы ещё про многоуровневую сортировку, reduce, сложный коллектор для мапы с возможностью указать тип используемой реализации и стратегию разрешения конфликтов, в случае совпадения ключей.
это что EntityFW из C# до java докатился?
На мой взгляд, было бы достаточно рассмотреть работу Stream API на коллекциях. Spring и база данных замутняют дело, и Stream API в итоге применяется не совсем по назначению.
Если начинать с БД, то лучше рассматривать, как формировать запросы, а не запрашивать сразу все данные и фильтровать на месте. Есть и решения с DSL для запросов, которые в итоге выглядят как использование streams.
Что мешало сгенерировать без базы нужные данные? С бд так действительно категорически нельзя работать
Практические примеры использования Stream API