Sökfunktion i Lovable: hitta poster med fritext eller innehåller-sökning

Guiden gäller sökning bland appens egna poster i databasen. Den handlar inte om AI-sökning med embeddings, som nyheten om Lovables embeddingmodell tar upp. Besluten om vilka fält som ska sökas, hur å, ä och ö ska behandlas och vad en tom träfflista ska säga finns i artikeln om sök och filter i appen. Här handlar det om tekniken bakom rutan.

Steg 1: ta reda på vilken sökning appen har nu

Lovable beskriver sin inbyggda backend, Cloud, som byggd på ”Supabase's open-source foundation”. Båda teknikerna i guiden finns beskrivna i Supabases och PostgreSQL:s dokumentation, men vad just din app använder ser du bara i koden. Fråga innan du ändrar något:

Förklara utan att ändra något: hur fungerar sökrutan på sidan
[Annonser]? Vilka fält söks? Används .ilike, .textSearch,
en filtrering bland rader som redan finns i webbläsaren
eller något annat? Visa kodraden för själva sökningen.

Svaret är ett exempel på vad du kan få, inte ett garanterat utfall. Det viktiga är kodraden. Filtrerar appen bara bland de rader som redan är inlästa i webbläsaren, söker den inte i hela databasen. Visar listan dessutom bara en sida i taget, missas poster på de andra sidorna; mer om det finns i artikeln om paginering.

Steg 2: förstå de två sorterna

Innehåller-sökning. Supabases JavaScript-referens beskriver .ilike så här: ”Match only rows where column matches pattern case-insensitively.” Exemplet söker med mönstret %lu%. Enligt PostgreSQL matchar % noll eller fler godtyckliga tecken, så mönstret betyder ”innehåller lu”. Därför hittar ström namnet Lundström. Men sökningen jämför bokstäver, inte ord: cykel hittar inte cyklar, och röd cykel hittar bara exakt den följden, inte ”cykel, röd”.

En fallgrop: % och _ är jokertecken även när användaren skriver dem. PostgreSQL anger att de måste föregås av ett escape-tecken, som standard bakstreck, för att sökas bokstavligt. Beställ det uttryckligen. PostgreSQL anger också att skiftlägesokänsligheten följer databasens aktiva lokal, så kontrollera att Å och å räknas lika i ditt prov i stället för att anta det.

Fritextsökning. Funktionen to_tsvector gör enligt Supabase om texten till sökbara token. I dokumentationens engelska exempel blir ”green eggs and ham” orden egg, green och ham: ”and” faller bort och ”eggs” blir ”egg”. Sökordet tolkas med websearch_to_tsquery, som ger en söksyntax som liknar webbsökmotorers: citattecken för fras, or och minus för att utesluta. I appens kod syns det som .textSearch('description', 'green eggs', { type: 'websearch' }). Supabase visar också en genererad kolumn med den färdiga ordlistan och ett GIN-index på den, och skriver att det gör frågorna ”much faster”. Siffror anges inte, och guiden lovar inga.

Priset är att fritextsökning jämför ord. Räkna med att ström inte hittar Lundström. Början av ett ord kräver prefixsökning, som Supabase visar med :* i to_tsquery.

Steg 3: kontrollera språket innan du lovar böjningar

Att ”eggs” blir ”egg” beror på språkkonfigurationen. PostgreSQL beskriver normaliseringen som att stora bokstäver nästan alltid görs små och att ändelser ofta tas bort, ”such as s or es in English”. Alla Supabase-exempel använder 'english'. Utelämnas konfigurationen används databasens standardinställning default_text_search_config. Engelska regler är skrivna för engelska ändelser, så räkna inte med att de slår ihop cykel och cyklar.

För svenska visar PostgreSQL-dokumentationen ordboken swedish_stem, ”snowball stemmer for swedish language”, i ett exempel. En konfiguration som heter swedish står däremot inte uttryckligen på de sidor guiden bygger på, och redaktionen har inte kunnat se en Lovable Cloud-databas. Fråga därför din egen:

Kör två läsfrågor mot databasen och visa resultatet. Ändra inget.
select cfgname from pg_catalog.pg_ts_config order by cfgname;
show default_text_search_config;

Katalogen pg_ts_config innehåller enligt PostgreSQL databasens textsökkonfigurationer. Facit: finns swedish i listan kan du beställa fritext med den. Saknas den, beställ inte böjningshantering; välj innehåller-sökning eller acceptera att böjda former inte matchar. Oavsett vad listan säger avgör prov 1 och 3 nedan om böjningarna faktiskt slås ihop.

Steg 4: välj och beställ

Behöver appen båda, till exempel namnsökning och sökning i beskrivningar, beställ en i taget och prova var för sig. Beställningarna nedan är exempel med samma omslutning; bara själva sökningen skiljer.

Gör sökrutan på sidan [Annonser] till en sökning i databasen,
inte bara bland raderna som redan finns i webbläsaren.
Sök i fälten [titel] och [beskrivning] med ilike och mönstret
%sökord%, så att stora och små bokstäver inte spelar roll.
Om sökordet innehåller % eller _ ska tecknen sökas bokstavligt.
Ändra ingen annan funktion. Visa koden och SQL:en innan du kör.

Gör sökrutan på sidan [Annonser] till en sökning i databasen,
inte bara bland raderna som redan finns i webbläsaren.
Sök i fälten [titel] och [beskrivning] med en genererad kolumn
byggd med to_tsvector och konfigurationen [namnet från steg 3],
ett GIN-index på kolumnen och websearch-syntax för sökordet.
Ändra ingen annan funktion. Visa koden och SQL:en innan du kör.

Lovables dokumentation anger att schemaändringar görs med SQL-migreringar, så beställning B ger en migrering. Läs den innan du godkänner: där ska stå generated always as, to_tsvector med den konfiguration du valde och using gin. Står det 'english' fast du valde något annat, be om en rättad migrering.

Steg 5: tio sökningar med förväntat utfall

Lägg in fem påhittade poster via More → Database, där Lovable anger att du kan se tabellerna och redigera poster, och ta bort dem efteråt. Fyll titel och beskrivning så här:

• P1 Röd cykel säljes. Damcykel med tre växlar, hämtas i Lundby.
• P2 Cyklar för barn. Två barncyklar, 16 och 20 tum.
• P3 Bokhylla i ek. Fem hyllplan.
• P4 Åkgräsklippare. Beskrivningen lämnas tom.
• P5 Rabatt 50 % på kaffe. Gäller vid Lundströms café.

Läs igenom facit nedan och stryk kolumnen för den sökning du inte beställde. Sök sedan och skriv det faktiska utfallet bredvid.

Läs avvikelserna som diagnos. Ger 4 och 5 träff fast du beställde fritext, har appen troligen en innehåller-sökning. Ger 1 och 3 olika träffar med fritext, slås böjningarna inte ihop i din databas. Ger 7 träff på P1 med fritext, fungerar inte uteslutningen. Saknas P4 i prov 9, har den tomma beskrivningen gjort posten osökbar. Visa Lovable sökordet, det förväntade och det faktiska utfallet, och be om en rättning av just den raden.

Källor och avgränsning

• Lovable: Cloud – grunden i Supabase i steg 1, SQL-migreringar i steg 4 och Database-ytan i steg 5.
• Supabase: ilike – beskrivningen och mönstret %lu% i steg 2.
• Supabase: Full Text Search – to_tsvector, websearch_to_tsquery, textSearch, genererad kolumn, GIN-index, prefix med :* och exemplen med 'english' i steg 2 och 3.
• PostgreSQL: Pattern Matching – jokertecknen % och _, escape-tecknet och lokalen för ILIKE i steg 2.
• PostgreSQL: Introduction (Full Text Search) – normalisering och default_text_search_config i steg 3.
• PostgreSQL: psql Support – ordboken swedish_stem i exemplet i steg 3.
• PostgreSQL: pg_ts_config – katalogen som listar konfigurationerna i steg 3.

Källorna kontrollerades 31 oktober 2026. Ingen Lovable Cloud-databas har varit tillgänglig för redaktionen, så guiden påstår inte att svensk böjningshantering finns där och anger inga prestandasiffror. Prompterna är exempel och testlistan är ditt eget prov.