Java: fill the gaps

Полезное в PostgreSQL, часть 2 Прошлый пост собрал столько огоньков, что аж на душе потеплело, спасибо❤️ Продолжим наш ликбез по SQL. Сегодня расскажу про 3 похожие конструкции для вложенных запросов: CTE, View и Materialized View. ⭐️ Сommon Table Expression (СТЕ) выглядит так:

WITH cte_name AS (
  SELECT …
)
SELECT … FROM cte_name;

cte_name используется как источник данных ⭐️ VIEW и MATERIALIZED VIEW выглядят похоже:

CREATE (MATERIALIZED) VIEW view_name AS
   SELECT … ;

Полученное вью также используется как источник данных:

SELECT … FROM view_name;

В чём же разница? 1️⃣ Что именно хранится VIEW — это просто сокращение запроса, результат выполнения не сохраняется. При каждом FROM view_name запрос выполняется заново. MATERIALIZED VIEW сохраняет результат на момент выполнения. По сути создаётся временная таблица с копией данных. Важный момент: если исходные данные поменяются, они не повлияют на данные в MATERIALIZED VIEW. Для актуализации данных надо отдельно вызвать команду REFRESH. СТЕ как MATERIALIZED VIEW сохраняет результат выполнения и считается один раз. 2️⃣ Видимость CTE не существует сам по себе, за ним обязательно должен следовать запрос, который его использует. Можно сказать, что область видимости и время жизни CTE — один запрос. VIEW и MATERIALIZED VIEW доступны на уровне схемы, можно пользоваться много раз из разных мест. Удалять вью надо явно командой DROP. Это основные отличия. Есть ещё несколько, но не будем углубляться:) Примерные кейсы использования: 🔧 CTE — сделать сложные запросы более читаемыми 🔨 View — синоним для популярного запроса на выборку 🪛 Materialized view — снимок данных, которые долго считать с нуля, но к которым много обращений Теперь закрепим знания из этого и предыдущего поста небольшой задачкой✍️ Есть 2 таблицы: 🔸 from_table со столбцами id, firstname, lastname. 🔸 to_table со столбцами id, name Задача: перенести все строки из from_table в to_table, соединив firstname и lastname в одно поле name. После выполнения запроса from_table должен стать пустым. Попробуйте выполнить задачу ОДНИМ запросом. Онлайн Postgres: pgplayground Исходный код для экспериментов:

CREATE TABLE from_table(id int, firstname text, lastname text);
INSERT INTO from_table VALUES(1, 'F1', 'L1');
CREATE TABLE to_table(id int, name text);

✨ РЕШЕНИЕ ✨ Вспоминаем, что DELETE возвращает удалённые строки. Формируем из них СТЕ и передаём в INSERT:

WITH deleted_rows AS (
   DELETE FROM from_table
   RETURNING id, firstname || ' ' || lastname
)
INSERT INTO to_table
   SELECT * FROM deleted_rows;

Полезное в PostgreSQL, часть 1 Алгоритмы с литкода — это База. Но только для собеседований, на практике вы редко их встретите. С SQL ситуация обратная. На собесах спросят максимум джойн и HAVING, а на практике всё гораздо интереснее. Сегодня расскажу простые и полезные приёмы PostgreSQL, с которыми ваши скрипты станут симпатичнее💅 1️⃣ JOIN + USING Если при джойне таблиц имена столбцов совпадают, вместо ON используйте USING:

SELECT * FROM table1 
INNER JOIN table2 USING (user_id);

2️⃣ INSERT + SELECT Чтобы вставить в одну таблицу значения из другой, нет смысла вытаскивать данные отдельно. INSERT и SELECT прекрасно комбинируются:

INSERT INTO users (id, name)
   SELECT user_id, fullname FROM customers;

3️⃣ RETURNING Чтобы после вставки вернуть новые строки, отдельный SELECT не нужен. Добавьте RETURNING для нужных столбцов:

INSERT INTO users VALUE (…)
   RETURNING id;

Обычно возвращают id, но можно вернуть несколько столбцов и даже *. Для DELETE RETURNING тоже работает и возвращает удалённые строки. 4️⃣ Тестовые данные Для генерации простейших тестовых данных через SQL вам пригодятся: 🔸 generate_series(a, b) — последовательность целых чисел от a до b. Той же функцией генерятся даты в заданном диапазоне, синтаксис смотрите в документации 🔸 random() — случайное число от 0 до 1 🔸 md5(а) — хэш числа а. Помогает превратить результат random() в строку Дальше комбинируем. Например, так:

INSERT INTO t
   SELECT id,    // 1, 2,…, 100
   'name' || id, // name1,…, name100
   random(),
   md5(random()::text) 
FROM generate_series(1,100) id;

Одним запросом получаем 100 строк в базе! Приёмы выше хоть и простые, но пригодятся на большинстве проектов. Пользуйтесь и ставьте огонёчек, если нужна вторая часть🔥

IDEA: шорткаты для сверхзвуковой навигации по коду 🚀 Посмотреть список методов: Ctrl + F12 Быстро найти нужный метод или узнать, что вообще умеет класс 🚀 Найти класс или файл в проекте: Shift-Shift Откроется строка поиска, можно ввести начало имени или аббревиатуру класса 🚀 Перейти к определению: Ctrl + B Для переменных — переходит к месту, где она была объявлена, для методов — к их реализации 🚀 Вернуться в предыдущий класс:

Ctrl + Alt + ⬅️
Ctrl + Alt + ➡️

IDEA хранит небольшую историю перемещений, по которой можно перемещаться стрелками. Так очень удобно править несколько связанных файлов 🚀 Найти строку по номеру: Ctrl + G Когда коллега пишет: "проверь условие в строке 850", можно не проматывать огромный класс, а быстро перейти на нужную строку Очень удобные шорткаты, обязательно попробуйте🔥

Апдейт по фичам java 23 ⚡️ Новость 1 ⚡️ Derived records не войдут в java 23. Причина прозаична и близка каждому из нас — её просто не успели доделать:) Фича поедет в следующий релиз, и пощупать её можно будет зимой. ⚡️ Новость 2 ⚡️ Еще один кандидат в java 23, который не смог — это String templates. Но тут история другая. Напомню, в чём идея темплейтов. Есть две стратегии работы со строками: 🔸 Конкатенация — собираем строку по частям:

String str = "Hello, " + name + "!";

Этот подход использует StringBuilder, метод concat и тд. 🔸 Интерполяция — замена переменных внутри шаблона:

String name = "Jake";
String str = "Hello, ${name}!";

В чистом виде в java такого нет. Отдаленно похожи Formatter и MessageFormat, но там вместо переменных какие-то %s и %d, а переменные стоят отдельно:

String.format("%d plus %d equals %d", x, y, x + y);

А так чистокровная интерполяция выглядит в Kotlin:

"$x plus $y equals ${x + y}"

Новые String templates реализуют своеобразный вариант java интерполяции. В начале строки добавляется STR, переменные обрамляются в \{}

int x = 10, y = 20;
String str = STR."\{x} + \{y} = \{x + y}";
// "10 + 20 = 30"

❓ Зачем они добавили префикс STR? Почему нельзя сделать как в котлине? По 2 причинам: 1️⃣ Для обратной совместимости На джаве написано много кода и библиотек. Некоторые из них используют формат с фигурными скобками, и будет обидно, если этот код перестанет компилироваться. Чтобы этого избежать, решили явно обозначать строки для интерполяции 2️⃣ Для других обработчиков По задумке авторов другие процессоры могут делать больше, чем просто подстановку переменных. Например, собрать и провалидировать SQL запрос:

String sql = DB."select from users where id=/{id}";

❓ Что пошло не так? Разработчики собрали фидбэк и решили, что процессоры (STR, DB, etc) — это лишнее усложнение и очень странный API. Я с ними согласна, выглядит как работа со статическими полями, и вряд ли кому-то нужно что-то большее, чем работа со строками. ❓ Что в итоге с интерполяцией? Brian Goetz (архитектор java) написал: The remaining question that everyone is probably asking is: “so how do we do interpolation.” The answer there is “ordinary library methods”. = в текущем виде фича не будет реализована, интерполяции как в других языках тоже не будет, всё остаётся как есть. Напомню, что идея String templates появилась в 2021 году, прошлой осенью вышла preview версия. И только сейчас разработчики поняли, что фича так себе. Косяки бывают на всех проектах, это нормально:)

Новая фича Java 23: Derived Record Внимательные читатели давно заметили, что я люблю разбирать джаву и разное API с точки зрения дизайна. Смотреть, как решается исходная проблема и насколько удобно и адекватно решение. Сегодня сяду на любимого конька и расскажу о новом синтаксисе, который появится в java 23 — Derived Record. Напомню, что records компилируются в final классы с final полями. Неизменяемые переменные — тренд последних лет. В этом подходе данные не меняются, а при модификации создаются новые объекты. Недостаток очевиден — чтобы создать объект на основе предыдущего, надо написать довольно много кода. Возьмём простой пример — record Point с двумя полями: Х и Y:

record Point(int x, int y) { }
Point p1 = new Point(1,1);

Допустим, нам нужна точка p2, у которой Х в 2 раза больше, чем у p1:

Point p2 = new Point(p1.x()*2, p1.y()); 

Надо прочитать ВСЕ поля исходного объекта и передать их в конструктор с нужными модификациями. Даже в классе с двумя полями надо напрячь глаза, чтобы понять, какой параметр меняется. В реальной жизни полей больше, и получается максимально унылая простыня кода. Вместо конструктора удобно использовать with методы:

Point p2 = p1.withX(p2.x()*2);

Сразу видно параметр, которым отличаются точки🔥 With методы — отличное решение, но не идеальное. Возьмём случай, когда между полями должны соблюдаться некоторые соотношения. Например, Х всегда должен быть больше Y. With методы работают только с одним полем и не знают про дальнейшие изменения. Поэтому сложная валидация в них затруднительна. После вызова

Point p3 = p1.withX(p1.x() - 5);

получаем объект со сломанным инвариантом. Мы не знаем, вызовет ли пользователь потом withY, и не можем это проконтролировать. Новый JEP работает с такими случаями и предлагает создавать объекты так:

Point p4 = p1 with {
  x *= 2;
  y *= 2;
};

🔸 Названия полей p1 берутся в качестве локальных переменных с теми же именами 🔸 Выполняются преобразования в скобках 🔸 После выполнения блока вызывается канонический конструктор Point, где находится валидация полей 🔸 Полученный объект присваивается объекту p4 В целом всё неплохо, но возникает вопрос целесообразности. На моей практике рекордс обычно используют как контейнер данных, который редко меняется. Если всё же меняется, то обычно это простая логика, куда бы идеально вписались with методы. Если бы records превращались в классы с готовыми with методами — было бы супер удобно. Я редко встречала в рекордах сложную валидацию и жёсткие отношения между полями. Мне кажется, добавлять новый синтаксис для таких случаев избыточно. Если нужна проверка инвариантов, можно написать свой метод. Поэтому вердикт новой фиче — сомнительно, но окэй. Я бы потратила человеко-часы на что-нибудь другое🙂 К слову, это уже вторая фича java 23, которая не вызвала у меня восторга. Первой были Gatherers, почитать можно тут А как вам новый синтаксис в рекордах? 🔥 - огонь, очень полезно 👍 - не вау, но пусть будет ❤️ - просто спасибо за пост:)

5 ошибок при использовании Optional Optional — супер удобный инструмент, который появился в java 8. В документации его цель явно обозначена — показать, что результат вызова метода может отсутствовать. Например, функция поиска может найти нужный элемент, а может и не найти. В этой ситуации отлично подойдёт Optional:

Optional<String> search();

С виду всё просто и понятно. Тем не менее, на практике Optional часто используется некорректно, код получается сложным или плохо читаемым. Самые популярные ошибки: 1️⃣ Использовать Optional во входных параметрах и конструкторах

❌ void init(Optional<String> value) {…}

Приходится добавлять лишние обёртки и проверки. ✅ Лучше проверять параметры на null в начале метода:

void init (String value) {
    if (value == null) …
}

2️⃣ Возвращать Optional при наличии дефолтного значения

❌ return Optional.ofNullable(value).orElse("default");
✅ return value == null ? "default" : value;

3️⃣ Обрабатывать Optional не сразу и тащить его далеко по коду. Идеально, если обработка происходит сразу после возвращения из метода:

Optiona<String> valueOpt = …
String value = valueOpt.orElse("default");

4️⃣ Возвращать Optional для коллекций

❌ public Optional<List<Integer>> search(…)

Если элементов нет, верните пустой список:

✅ public List<Integer> search(…) {
   … return List.of();
}

5️⃣ Неоптимальная работа с примитивами Для int, long и double есть специальные классы: OptionalInt, OptionalDouble и OptionalLong. У них нет затрат на создание объекта, а код становится чуть короче и понятнее. Методов меньше, чем в классическом Optional, но при интенсивной работе с примитивами возможен прирост производительности. Ответ на вопрос перед постом Входные параметры лучше проверять внутри метода:

❌ List<Student> search(Optional<String> city)
❌ void init(Optional<String> conf)

Лучше вернуть пустой список, если элементов нет: ❌ Optional<List<Student>> all()