Unknown data type: „JSON” podczas testowania z użyciem h2

0

Cześć wszystkim ,

Czy może ktoś z was napotkał się z problemem z którym niestety próbuje się uporać . Mianowicie używamy bazy danych Postgresql a do testów h2 . Kolumna w tabeli w bazie postgresql jest typu jsonb, a jak wiadomo h2 nie wspiera json i tu tez podczas testowania dochodzi do kolizji .
Unknown data type: „JSON”

Java + Spring

0

tak widziałam to , niestety nie pomaga

0

Szybkie google pokazuje, że po stronie H2 tworzysz swój typ danych i nazywasz go jsonb:
CREATE domain IF NOT EXISTS jsonb AS other;

https://www.h2database.com/html/commands.html#create_domain

Jeśli H2 nie zna jsonb, to funkcji, które na nim operują tym bardziej, wiec jeśli używasz jakichś funkcji postgresowych do operowania na takim typie danych, to może zajść potrzeba zdefiniowania odpowiedników w H2.

0

Cześć dzięki za odpowiedz , a masz pomysł gdzie to mogę w kodzie zaimplementować ?

0

Używasz jakichś narzędzi do migracji, masz jakiś jeden skrypt który stawia wszystko przy starcie, czy schema stawia się automagicznie?

Obstawiałbym jakiś skrypt migracyjny, taki który odpala się tylko w testach zanim zacznie się stawiać właściwa schema. Taki Flyway pozwala dorzucać SQLe z migracjami do testów, a o kolejności zapuszczania migracji decydują numery wersji więc powinno się dać wepchnąć migrację definiującą typy i funkcje, Liquibase pewnie jest coś podobnego.

A możesz też próbować pozbyć się H2 i spróbować https://www.testcontainers.org/ - nie używałem ale zawsze to jakaś alternatywa dla użerania się z bolączkami H2.

0

Zauważ, że konstrukcja tego własnego typu JSONB wygląda następująco: CREATE domain IF NOT EXISTS jsonb AS other. Jest to operacja idempotentna (po ludzku: przy pierwszym wywołaniu zostanie utworzony nowy typ, zaś samo polecenie może być uruchamiane wielokrotnie bez szkody dla testów i bez zmiany efekt końcowego).

Dzięki temu możesz umieścić tę komendę w ramach tworzenie konfiguracji dla testu.

W JUnit byłyby to adnotacje @BeforeClass dla wszystkich testów z danej klasy albo @Before dla metody z klasy testowej. Uruchamianie raz dla klasy wydaje się bardziej ekonomiczne.
Masz też inne możliwości, ale pytanie "gdzie to w kodzie zaimplementować" było dość podstawowe, dlatego wydaje mi się, że te sugestie z "before" będą dla Ciebie bardziej przystępne.

1
superdurszlak napisał(a):

Używasz jakichś narzędzi do migracji, masz jakiś jeden skrypt który stawia wszystko przy starcie, czy schema stawia się automagicznie?

Obstawiałbym jakiś skrypt migracyjny, taki który odpala się tylko w testach zanim zacznie się stawiać właściwa schema. Taki Flyway pozwala dorzucać SQLe z migracjami do testów, a o kolejności zapuszczania migracji decydują numery wersji więc powinno się dać wepchnąć migrację definiującą typy i funkcje, Liquibase pewnie jest coś podobnego.

A możesz też próbować pozbyć się H2 i spróbować https://www.testcontainers.org/ - nie używałem ale zawsze to jakaś alternatywa dla użerania się z bolączkami H2.

 <property name="meta_data.type" value="text" dbms="h2"/>
    <property name="meta_data.type" value="jsonb" dbms="postgresql"/>

    <changeSet author="d.wroblewski" id="014-updated-joblist-schema">
        <addColumn tableName="joblist">
            <column name="meta_data" type="${meta_data.type}"/>
        </addColumn>
    </changeSet>

dwie dodatkowe linijki kodu zalatwily sprawe. Dzieki

1 użytkowników online, w tym zalogowanych: 0, gości: 1