Виправлення помилки завантаження Spring: типи Character Varying і Smallint не мають оператора

Поширені підводні камені із запитами Spring Boot SQL: обробка невідповідностей типів у PostgreSQL

Як розробники, ми всі стикалися з загадковими повідомленнями про помилки, які, здавалося б, виникають нізвідки. Хвилинку, наш Додаток Spring Boot працює безперебійно; далі ми спостерігаємо помилку про несумісні типи даних. 😅 Це водночас засмучує та бентежить, особливо коли маєш справу зі складними налаштуваннями запитів.

Нещодавно я зіткнувся з помилкою PostgreSQL у Spring Boot: "оператор не існує: змінний символ = smallint." Це повідомлення з’явилося під час спроби використати a Набір переліків у реченні IN SQL-запиту. Невідповідність між типом enum і типом стовпця бази даних спричинила неочікувану помилку в тому, що здавалося простим кодом.

Хоча є спокуса звинуватити в цьому примхи бази даних або Spring Boot, справжня проблема часто полягає в тому, як перераховуються типи баз даних. Переліки Java, коли вони зіставлені з базами даних, вимагають особливої ​​обробки, особливо з PostgreSQL. Розуміння цих деталей може заощадити час і запобігти майбутнім проблемам під час роботи з переліками у Spring Boot.

У цьому посібнику я поясню, як я визначив проблему та пройшов практичне вирішення. Від мого власного шляху налагодження до конкретних виправлень коду ви отримаєте інструменти, необхідні для уникнення невідповідностей типів у ваших запитах і забезпечення безперебійної взаємодії з базою даних. 🔧

Усунення невідповідностей типів даних під час Spring Boot за допомогою PostgreSQL

При роботі з Весняний черевик і PostgreSQL, розробники часто стикаються з проблемами невідповідності типів, особливо з enum. У цьому випадку помилка «operator does not exist: character varying = smallint» виникає через те, що PostgreSQL не може безпосередньо інтерпретувати Java enum як тип SQL у власних запитах. Тут сутність SystemAccounts містить поле userCode, представлене переліком AccountType, який відображає такі значення, як «PERSONAL» або «CORPORATE» у Java. Однак під час спроби власного SQL-запиту з набором переліків PostgreSQL не може автоматично зіставити типи переліків, що призводить до цієї помилки. Щоб подолати це, дуже важливо перетворити enum на рядок перед тим, як передати його в запит. 🎯

У наданому рішенні ми починаємо з коригування зіставлення enum у SystemAccounts за допомогою анотації @Enumerated(EnumType.STRING). Це вказує JPA зберігати кожен AccountType як читабельний рядок замість числового порядкового номера. Це невелика зміна, але вона спрощує обробку даних у майбутньому, уникаючи числових значень, які ускладнюють налагодження в базі даних. У нашому репозиторії ми можемо використовувати спеціальну анотацію @Query, щоб визначити логіку SQL. Однак, оскільки PostgreSQL все ще потребує переліків як рядків у запиті, нам потрібно обробити значення AccountType у форматі рядка перед тим, як передати їх.

API CriteriaBuilder пропонує динамічне вирішення цієї проблеми. Використовуючи CriteriaBuilder, ми можемо уникнути рідного SQL, створюючи запити програмним шляхом у Java. Цей підхід дає нам змогу додавати фільтри enum без написання SQL вручну, що зменшує кількість помилок SQL і сприяє зручності обслуговування. У нашому сценарії ми створюємо список предикатних умов на основі кожного значення рядка enum, використовуючи cb.equal() для відповідності кожному AccountType у Set. Потім cb.or() поєднує ці предикати, дозволяючи декілька значень в одному запиті. Це гнучке налаштування динамічно керує перетворенням переліку в рядок, мінімізуючи проблеми сумісності з PostgreSQL.

Нарешті, рішення включає модульний тест для перевірки сумісності. Використовуючи JUnit, ми підтверджуємо, що кожен AccountType працює з нашим запитом, підтверджуючи, що поле userCode може зберігати значення «PERSONAL» або «CORPORATE» і отримувати їх без помилок. Цей метод перевірки спочатку встановлює необхідні значення AccountType і запускає запит findAllByUserCodes(), щоб перевірити результати. Додавання перевірок assertNotNull() і assertTrue() гарантує, що ми не зустрінемо нульові чи неправильні значення, гарантуючи, що наше рішення ефективно обробляє всі випадки. З таким налаштуванням програма краще підготовлена ​​до обробки запитів enum у різних умовах у виробництві. 🧪

// Problem: PostgreSQL expects specific data types in queries.
// Solution: Convert enums to strings for query compatibility with PostgreSQL.
// This Spring Boot backend solution is clear, optimized, and includes type checks.

@Entity
@Table(name = "system_accounts")
@Getter
@Setter
public class SystemAccounts {
    @Id
    @Column(name = "id", nullable = false)
    private UUID id;
    @Column(name = "user_code")
    private String userCode;  // Store as String to avoid type mismatch
}

// Enumeration for AccountType
public enum AccountType {
    PERSONAL,
    CORPORATE
}

// Repository Query with Enum Handling
@Query(value = """
    SELECT sa.id FROM system_accounts sa
    WHERE sa.user_code IN :accountTypes""", nativeQuery = true)
Optional<List<SystemAccounts>> findAllByUserCodes(@Param("accountTypes") List<String> accountTypes);
// This query accepts a List of strings to avoid casting issues.

// Convert AccountType enums to Strings in Service
List<String> accountTypeStrings = accountTypes.stream()
    .map(Enum::name)
    .collect(Collectors.toList());

// Using CriteriaBuilder to dynamically handle enums in queries with automatic type checking.
// This approach uses Java’s Criteria API to avoid type mismatches directly in the code.

public List<SystemAccounts> findAllByUserCodes(Set<AccountType> accountTypes) {
    CriteriaBuilder cb = entityManager.getCriteriaBuilder();
    CriteriaQuery<SystemAccounts> query = cb.createQuery(SystemAccounts.class);
    Root<SystemAccounts> root = query.from(SystemAccounts.class);
    Path<String> userCodePath = root.get("userCode");
    List<Predicate> predicates = new ArrayList<>();

    // Add predicates for enum values, converting to String for matching
    for (AccountType type : accountTypes) {
        predicates.add(cb.equal(userCodePath, type.name()));
    }

    query.select(root)
         .where(cb.or(predicates.toArray(new Predicate[0])));
    return entityManager.createQuery(query).getResultList();
}

// This JUnit test ensures both solutions handle enums correctly with PostgreSQL.
// Tests database retrieval for both AccountType values: PERSONAL and CORPORATE.

@SpringBootTest
public class SystemAccountsRepositoryTest {
    @Autowired
    private SystemAccountsRepository repository;

    @Test
    public void testFindAllByUserCodes() {
        Set<AccountType> accountTypes = Set.of(AccountType.PERSONAL, AccountType.CORPORATE);
        List<SystemAccounts> results = repository.findAllByUserCodes(accountTypes);

        // Verify results are returned and types match
        assertNotNull(results);
        assertTrue(results.size() > 0);
        results.forEach(account ->
            assertTrue(account.getUserCode().equals("PERSONAL") || account.getUserCode().equals("CORPORATE"))
        );
    }
}

Перетворення Enum на рядок у PostgreSQL за допомогою Spring Boot

При використанні Весняний черевик з PostgreSQL обробка переліків у запитах до бази даних часто вимагає особливої ​​уваги, особливо коли переліки задіяні в рідні запити SQL. За замовчуванням PostgreSQL не підтримує переліки Java безпосередньо, а натомість очікує сумісного типу даних, наприклад varchar або текст у запитах. Наприклад, коли нам потрібно відфільтрувати результати на основі такого переліку, як AccountType, PostgreSQL вимагає від нас перетворити перелік Java на рядкове значення перед виконанням запиту. Це перетворення запобігає поширеній помилці «оператор не існує», яка виникає, коли база даних намагається порівняти перелік із несумісним типом, таким як smallint або зміна символів.

Один із способів вирішення цієї проблеми – використовувати @Enumerated(EnumType.STRING) анотація у Spring Boot, яка зберігає enum як рядкові значення безпосередньо в базі даних. Однак для сценаріїв, що включають власні запити, часто необхідно перетворити переліки на рядки в самому запиті. За допомогою таких методів, як .stream() і map(Enum::name), ми можемо створити список представлень рядків для наших значень enum, які потім можна передати в PostgreSQL без проблем з невідповідністю типів. Цей підхід забезпечує гнучкість, дозволяючи фільтрувати за кількома значеннями AccountType безпомилково.

Для програм із більш складним використанням enum інший підхід полягає у використанні CriteriaBuilder API, який дозволяє нам динамічно створювати запити безпечним способом без ручного написання SQL. Цей API особливо корисний для створення повторно використовуваного та незалежного від бази даних коду, оскільки він автоматично переводить переліки у сумісні типи баз даних, зменшуючи ризик помилок типу. За допомогою цього методу процес побудови запиту спрощується, а розробники отримують гнучкість для обробки різних фільтрів на основі переліку в єдиний спосіб.