Gjør uleselig SQL på én linje om til en pent innrykket spørring – 18 dialekter, alt i nettleseren din.
SQL kommer sjelden lesbar: én endeløs linje ut av en ORM, alle nøkkelord med små bokstaver i en logg over trege spørringer, innrykket ødelagt av en chatteklient. Å formatere den for hånd før du i det hele tatt kan lese den koster ti minutter – og lesingen er der feilene sitter: en join-betingelse som stille ble et filter, en OR som binder bredere enn den som skrev den trodde, en underspørring tre nivåer ned. Lim den inn her, så kommer den tilbake med én klausul per linje, justert nesting og nøkkelord i den bokstavstørrelsen du foretrekker.
Jobben gjøres av en ekte parser, ikke en haug med regulære uttrykk. Spørringen deles i tokens, forstås som et tre av klausuler og skrives ut på nytt, og det er derfor kommentarer blir stående på linjen de ble skrevet på, strenglitteraler overlever urørt selv når de inneholder ord som SELECT eller FROM, og en vindusfunksjon beholder OVER (PARTITION BY … ORDER BY …)-blokken sin pent nestet. Atten dialekter tilbys – Standard SQL, PostgreSQL, MySQL, MariaDB, SQLite, SQL Server (T-SQL), Oracle PL/SQL, BigQuery, Snowflake, Redshift, Spark, Trino, Hive, Db2, Db2 for i, TiDB, SingleStore og N1QL – og valget er ingen pynt: dollar-sitering i PostgreSQL ($$body$$) og klammer i T-SQL ([dbo].[table]) er parsefeil under Standard SQL og formateres perfekt under riktig dialekt. Plassholdere som ?, :name, $1 og @name gjenkjennes i alle dialekter og slippes gjennom ordrett, så SQL kopiert rett ut av en spørringslogg blir ikke ødelagt.
To ærlige begrensninger. Formatereren sjekker bare at teksten er grammatisk gyldig SQL for den valgte dialekten: den vet ingenting om tabellene dine, så den formaterer gjerne en spørring som viser til en kolonne som ikke finnes, og den kjører aldri noe. Når teksten ikke kan tolkes, sier den hvor parseren ga opp, med linje og kolonne, i stedet for å levere tilbake et halvformatert rot. Personvernet er grunnen til å formatere her framfor på et tilfeldig nettsted: spørringer fra produksjon bærer tabellnavn, forretningslogikk og noen ganger persondata. Biblioteket (sql-formatter, MIT, servert fra vai.la og lastet ned bare ved din første formatering) kjører inne i nettleseren din.
Nei. Spørringen tolkes og skrives ut på nytt av JavaScript på din egen enhet – ingenting lastes opp, logges eller lagres. Det betyr noe, for ekte spørringer avslører skjemaet ditt, forretningsreglene dine og noen ganger persondata som ligger i litteraler. Etter første formatering kan du koble fra internett, og det virker fortsatt.
Den databasen din snakker. Standard SQL dekker de fleste vanlige spørringer, men databasespesifikk syntaks krever den tilhørende dialekten: [klammer] krever SQL Server (T-SQL), $$dollar-sitering$$ krever PostgreSQL. En parsefeil på gyldig SQL løses som regel ved å bytte dialekt.
Nei. Bare mellomrom, linjeskift og bokstavstørrelsen på nøkkelord endres. Identifikatorer, strenglitteraler, tall og kommentarer kommer tilbake nøyaktig slik de ble skrevet, så den formaterte spørringen er ekvivalent med originalen.
Fordi parseren traff på noe den ikke fikk til å passe inn i grammatikken, på linjen og kolonnen som vises. Tre vanlige årsaker: en skrivefeil som et manglende komma, anførselstegn eller parentes; et fragment som ikke er en fullstendig setning; eller databasespesifikk syntaks med feil dialekt valgt.
Ja. Posisjonelle (?), nummererte ($1) og navngitte (:name, @name) plassholdere gjenkjennes i alle dialekter og skrives tilbake uendret, så du kan lime inn rett fra en spørringslogg eller feilsøkingsutskriften til et rammeverk.
Ja. Setninger skilt med semikolon formateres etter hverandre, med en blank linje mellom. Inndataene er begrenset til 300 000 tegn slik at siden aldri fryser; er filen større, del den opp.
Vai.la gjør enhver URL om til en kortlenke med klikkstatistikk, QR Code og din egen biolink.
Vai.la er ikke ansvarlig for hvordan verktøyene brukes, eller for beslutninger tatt på grunnlag av resultatene.