Dokumentacja dla definicji kolejek SQL

Spis treści

Wprowadzenie do walidacji zapytań SQL

Walidacja składni SQL

Walidacja liczby instrukcji

Walidacja trybu tylko do odczytu

Walidacja listy ID elementów zleceń

Walidacja wykonalności

Wprowadzenie do walidacji zapytań SQL

Comarch APS umożliwia wykorzystywanie niestandardowych definicji kolejek SQL do planowania pozycji zleceń. Więcej informacji na temat definiowania i używania tych kolejek SQL znajdziesz w Dokumentacji Użytkownika.

Poniższa dokumentacja określa zasady, według których zapytania SQL są walidowane w systemie.

W systemie Comarch APS, zapytania SQL wykorzystywane do definiowania kolejek podlegają rygorystycznym procesom walidacji. Celem tego procesu jest zapewnienie bezpieczeństwa, stabilności i wydajności systemu. Walidacja odbywa się w kilku etapach, aby zagwarantować, że każde zapytanie jest poprawne składniowo, bezpieczne i zgodne z przeznaczeniem.

Walidacja składni SQL

Pierwszy etap ma na celu wykrycie podstawowych błędów składniowych, zanim zapytanie zostanie poddane dalszej weryfikacji.

Poprawne przykłady

Zapytania, które przechodzą walidację składni, obejmują standardowe operacje SQL.
System jest w stanie poprawnie zinterpretować następujące konstrukcje:

  • Proste zapytania SELECT z klauzulą WHERE

Przyklad
SELECT id FROM cdn.production_orders WHERE id_from_erp = 1
  • Minimalne zapytania SELECT
Przyklad
SELECT 1
  • Zapytania z komentarzami (zarówno blokowymi /* … */ jak i liniowymi — …)
Przyklad
SELECT id /* comment */ FROM cdn.production_orders — single line comment
  • Zapytania z klauzulą JOIN
Przyklad

SELECT po.id, poe.element_id

FROM cdn.production_orders po

JOIN cdn.production_order_elements poe ON po.id = poe.production_order_id

  • Instrukcje modyfikujące dane: INSERT, UPDATE oraz DELETE, pod warunkiem, że są one poprawne składniowo
Przyklad

INSERT INTO cdn.production_orders (id_from_erp, year) VALUES (1, 2025)

UPDATE cdn.production_orders SET status=1 WHERE id=1

DELETE FROM cdn.production_orders WHERE id=1

Najczęściej popełniane błędy

Zapytania, które nie przejdą walidacji, najczęściej zawierają proste błędy, takie jak:

  • Literówki w słowach kluczowych (np. SELCT zamiast SELECT)
Przyklad
SELCT * FROM cdn.production_orders
  • Niedomknięte literały znakowe , komentarze lub nawiasy
Przyklad

SELECT * FROM table WHERE name = 'unterminated string

SELECT * FROM table /* unterminated comment

SELECT * FROM [unclosed_bracket

SELECT * FROM table WHERE (column = 1

  • Niekompletne klauzule, np. WHERE bez warunku lub FROM bez nazwy tabeli
Przyklad

SELECT * FROM table WHERE

SELECT * FROM

  • Niedozwolone znaki specjalne w nazwach tabeli
Przyklad
SELECT * FROM table@#$%
  • Brak listy kolumn w instrukcji SELECT
Przyklad
SELECT WHERE
  • Niekompletne instrukcje
Przyklad

FROM table

INSERT INTO table VALUES

UPDATE table SET

Walidacja liczby instrukcji

Ten etap ma na celu upewnienie się, że Użytkownik przekazał dokładnie jedną instrukcję SQL. Zapobiega to przypadkowemu wykonaniu wielu zapytań (np. SELECT …; SELECT …), co mogłoby prowadzić do nieprzewidzianych skutków.

Dozwolone konstrukcje:

  • Pojedyncza instrukcja: System akceptuje zapytanie zawierające tylko jedną instrukcję SQL, np. SELECT 1.
  • Opcjonalny średnik na końcu: Dozwolone jest zakończenie pojedynczej instrukcji średnikiem, na przykład SELECT 1;. Średnik jest traktowany jako opcjonalny terminator, a nie jako separator kolejnej instrukcji.
  • Komentarze: Zapytania mogą zawierać komentarze, zarówno wieloliniowe (/* … */) jak i jednoliniowe (– …), umieszczone przed instrukcją, po niej lub w jej obrębie. System poprawnie je ignoruje podczas walidacji liczby instrukcji.

Niedozwolone instrukcje:

  • Wielokrotne instrukcje oddzielone średnikiem: Próba wykonania dwóch lub więcej instrukcji w jednym zapytaniu jest natychmiast odrzucana.
Przyklad

SELECT 1; SELECT 2

SELECT 1; DROP TABLE test

INSERT INTO table1 …; UPDATE table2 …

  • Nowe linie jako separator: Nawet jeśli instrukcje nie są oddzielone średnikiem, ale znajdują się w osobnych liniach, system również potraktuje to jako próbę wykonania wielu poleceń, co jest niedozwolone.
  • Kombinacja dozwolonych i niedozwolonych instrukcji: Jakikolwiek ciąg instrukcji, w którym choć jedna jest niedozwolona, zostanie odrzucony na etapie walidacji liczby instrukcji (poza etapem walidacji trybu tylko do odczytu, który ma własne, bardziej restrykcyjne zasady).

Uwaga
W przypadku błędu składniowego zapytania, walidacja liczby instrukcji jest pomijana. O wykrycie takich błędów dba wcześniejszy etap walidacji składni, który ma za zadanie zidentyfikować, czy zapytanie jest napisane poprawnie, niezależnie od liczby instrukcji. Dopiero poprawne składniowo zapytania są poddawane walidacji pod kątem liczby instrukcji.

Walidacja trybu tylko do odczytu

Jest to kluczowy etap, który blokuje polecenia modyfikujące dane oraz polecenia administracyjne. W tym trybie dozwolone są wyłącznie instrukcje SELECT.

Dozwolone: Wyłącznie zapytania SELECT.

Przyklad
SELECT id FROM cdn.production_orders WHERE id_from_erp = 1

Niedozwolone: Instrukcje takie jak INSERT , UPDATE , DELETE , DROP , CREATE czy GRANT. Łączenie dozwolonej instrukcji SELECT z niedozwoloną (DROP TABLE) również nie przejdzie walidacji.

Przyklad

INSERT INTO cdn.production_orders (id_from_erp, year, month, series, number, plan_from, status, priority, issued_at, update_date)

VALUES (1, 2025, 1, 'S’, 1, NOW(), 0, 1, NOW(), NOW())

UPDATE cdn.production_orders SET status=1 WHERE id=1

DELETE FROM cdn.production_order_elements WHERE id=1

DROP SCHEMA IF EXISTS cdn CASCADE;

CREATE TABLE cdn.test_table (id SERIAL PRIMARY KEY);

GRANT ALL ON SCHEMA cdn TO „ComarchAPS”;

SELECT id FROM cdn.production_orders; DROP TABLE cdn.production_orders;

Walidacja listy ID elementów zleceń

Ten etap jest specyficzny dla zapytań służących do planowania, ponieważ muszą one zwracać listę pojedynczych identyfikatorów z tabeli cdn.production_order_elements.

Kluczowe reguły:

  • Wynik zapytania musi zawierać tylko jedną kolumnę o nazwie id.
  • Tabela cdn.production_order_elements musi być głównym źródłem danych w głównym zapytaniu SELECT (oraz w każdej klauzuli UNION ALL).

Dozwolone konstrukcje:

  • Aliasy dla tabel i kolumn.
  • Złączenia (JOIN) z innymi tabelami, pod warunkiem, że w ostatecznym wyniku zwracane jest ID z cdn.production_order_elements.
  • Podzapytania (subquery), EXISTS oraz CTE (Common Table Expressions).
  • UNION ALL (gdy oba zapytania spełniają reguły).
Przyklad

SELECT id FROM cdn.production_order_elements WHERE status = 1

SELECT poe.id FROM cdn.production_order_elements poe WHERE poe.status = 1

SELECT poe.id

FROM cdn.production_order_elements poe

JOIN cdn.production_orders po ON poe.production_order_id = po.id

WHERE po.status = 1

WITH filtered_elements AS (

SELECT id, status FROM cdn.production_order_elements WHERE status = 1

)

SELECT id FROM filtered_elements

SELECT id FROM cdn.production_order_elements

WHERE id IN (SELECT id FROM cdn.production_orders WHERE year = 2025)

SELECT id

FROM cdn.production_order_elements

WHERE status = 8

ORDER BY priority DESC

limit 10

SELECT id FROM cdn.production_order_elements WHERE status = 8

UNION ALL

SELECT id FROM cdn.production_order_elements WHERE priority > 7

Niedozwolone konstrukcje:

  • Użycie innej tabeli jako głównego źródła danych.
  • Zwracanie dodatkowych kolumn lub użycie symbolu *.
  • Użycie funkcji agregujących (np. COUNT) lub instrukcji CASE.
  • Brak schematu w nazwie tabeli.
Przyklad

SELECT id, status FROM cdn.production_order_elements WHERE status = 1

SELECT id FROM cdn.production_orders WHERE status = 1

SELECT po.id

FROM cdn.production_order_elements poe

JOIN cdn.production_orders po ON poe.production_order_id = po.id

WHERE po.status = 1

SELECT * FROM cdn.production_order_elements WHERE status = 1

WITH filtered_elements AS (

SELECT id FROM cdn.production_orders WHERE status = 1

)

SELECT id FROM filtered_elements

SELECT poe.id, COUNT(*) as element_count

FROM cdn.production_order_elements poe

INNER JOIN cdn.production_orders po ON poe.production_order_id = po.id

WHERE po.year = 2024 GROUP BY poe.id HAVING COUNT(*) > 1

SELECT id,

CASE WHEN priority >= 8 THEN 'HIGH’ WHEN priority >= 5 THEN 'MEDIUM’ ELSE 'LOW’

END as priority_level

FROM cdn.production_order_elements

Walidacja wykonalności

Walidacja wykonalności stanowi ostatni etap procesu weryfikacji zapytań SQL w systemie Comarch APS. Jej celem jest szybkie sprawdzenie, czy zapytanie, które przeszło już wcześniejsze walidacje składni, liczby instrukcji oraz trybu tylko do odczytu, rzeczywiście może zostać wykonane bez błędów w środowisku uruchomieniowym.

Zasadniczo, jest to test „na żywo”, który symuluje wykonanie zapytania, aby potwierdzić, że nie wystąpią błędy podczas jego faktycznego działania. Ten etap jest kluczowy, ponieważ niektóre problemy nie są możliwe do wychwycenia na wcześniejszych etapach walidacji.

Czego dotyczy walidacja wykonalności?

  • Błędy w czasie wykonywania (runtime errors): Zapytanie może być poprawne składniowo, ale zawierać odniesienia do nieistniejących kolumn, tabel lub funkcji. Walidacja wykonalności wykryje te błędy, zanim zapytanie trafi do produkcyjnego planowania.
  • Problemy z uprawnieniami: Nawet jeśli zapytanie jest poprawne, może nie mieć uprawnień do dostępu do określonych zasobów. Ten etap weryfikuje, czy konto systemowe ma odpowiednie uprawnienia do wykonania zadanego zapytania, np. do odczytu danych z danej tabeli.
  • Niespójność danych: Choć zapytania mają być tylko do odczytu, błędy logiczne w klauzulach (WHERE, JOIN itp.) mogą prowadzić do nieprzewidzianych wyników lub błędów, które są wykrywane dopiero podczas próby ich wykonania.

Ten etap stanowi ostatnie sito bezpieczeństwa, zapewniając, że tylko w pełni funkcjonalne i bezbłędne zapytania mogą być używane do planowania w Comarch APS.

Czy ten artykuł był pomocny?

Wyślij opinie