Nastavení kompatibility – aneb jízda se zataženou parkovací brzdou(1. část)

Automaticky přeloženo z Deepl

Při přípravě kódu obvykle strávím nějaký čas nastavením databáze, zejména nastavením kompatibility. Často se stává, že některá nastavení neodpovídají osvědčeným postupům a během diskuze s vývojářem aplikace slyším „aha, tohle jsem nikdy neměnil“ nebo „nejsem si jistý dopadem, tak na to raději nesahejte“.

Protože mohou mít drastický dopad na výkon nebo chování vašich aplikací, zahájili jsme sérii blogových příspěvků, ve kterých se budeme některým z těchto „tajných“ nastavení věnovat.

První část nastavení kompatibility – dotazování podle vzorce

Tato nastavení nutí systém 4D chovat se tak, jak se choval ve verzi 2004, což snižuje soubor funkcí a výkon. Přitom je tak snadné je změnit, ale zákazníci se bojí neznámých vedlejších účinků.

QUERY BY FORMULA byla ve verzi v2004 poměrně pomalá (protože všechny záznamy byly přenášeny na klienta), bez velké přidané hodnoty. V důsledku toho ji většina vývojářů ignorovala. Pravidla byla změněna s verzí v11.

Příkaz QBF (v tomto blogovém příspěvku jen ve zkratce) umožňuje používat výpočty, například vyhledávání velikosti obrázku nebo délky textu. Výhody této funkce jsou poměrně zřejmé. Takové výpočty však nemohou používat index, takže jsou pomalejší než indexovaný dotaz.

Příkaz QBF toho však umí mnohem více! Dokáže kombinovat skupiny dotazů pomocí závorek: ((pole1=1) a (pole2=“A“)). NEBO ((field1=50) a (field2=“B“)).

Nepoužití příkazu QBF znamená spuštění dvou dotazů a použití sad, což vede k mnohem většímu síťovému provozu, větší závislosti na výkonu sítě a většímu zatížení serveru 4D. Optimalizátor dotazů serveru 4D Server automaticky zjišťuje nejlepší (nejrychlejší) způsob zpracování takových podmínek na polích stejné tabulky – nebo dokonce souvisejících tabulek.

A co je nejlepší, dokáže sám vytvářet vztahy (tzv. joiny), i když v režimu struktury není nakreslen žádný odkaz. Ano, můžete dynamicky sestavovat relace pro provádění dotazů (pokud je povolena volba „QUERY BY FORMULA Uses SQL Joins“).

Volba „QUERY BY FORMULA Uses SQL Joins“ může být matoucí, protože vůbec nesouvisí s SQL, měli byste ji vnímat spíše jako „QBF podporuje dynamické vztahy“.

Jako příklad použijme jednoduchou strukturu:

blank

Obě stránky QUERY i QUERY BY FORMULA bylo možné použít k vyhledávání pomocí relace, jako např:

QUERY BY FORMULA([Table_2];[Table_1]Field_2="1")

Ale pouze QBF umožňuje explicitně definovat vztah (což umožňuje použít jakýkoli možný vztah), místo aby vyžadoval již existující definovaný vztah. Nyní si představme, že mezi těmito dvěma tabulkami existuje druhá logická vazba, která však ještě neexistuje jako vztah 4D … Pole3 s polem2. QBY umožňuje zadat vztah za běhu:

QUERY BY FORMULA([Table_2]; ([Table_1]ID=$var)& \
([Table_1]Field_2=[Table_2]Field_3)).

Poznámka: Při použití dynamického spojení musí porovnávat dvě pole různých tabulek. Pokud je součástí dotazu, je to automaticky zpracováno jako spojení, aby se definoval vztah.

Pokud chcete vyhledat hodnotu v jiné tabulce, musíte ji nejprve přiřadit lokální proměnné. Tím jasně definujete, že ji chcete použít jako konstantu.

Povolení možnosti „QUERY BY FORMULA Uses SQL Joins“ je povinné, aby „nový“ editor dotazů(tj. editor dotazů zavedený s verzí v14) mohl používat relace. Důvod je jednoduchý, používá QUERY BY FORMULA příkaz interně.

Shrnutí:

  • QUERY BY FORMULA umožňuje používat závorky pro vyjádření složitých podmínek dotazu, zatímco QUERY umožňuje pouze vyjádření více podmínek OR nebo více podmínek AND, nikoli však kombinaci obou.
  • QUERY BY FORMULA podporuje spojování a dynamické dotazy.
  • QUERY BY FORMULA umožňuje používat vzorce, například velikost obrázku.
  • QUERY BY FORMULA je prováděn na serveru (podobně jako běžný dotaz). QUERY), přičemž poskytuje stejnou nebo dokonce vyšší rychlost, protože generuje méně síťového provozu ve srovnání s kombinací QUERY a množinových operací.

Všimněte si: vše výše uvedené platí pro klasický jazyk 4D. Kód založený na ORDAse vždy provádí na serveru.

Migrační práce nutné k zajištění kompatibility

Výše uvedená nastavení jsou v dialogu kompatibility viditelná pouze pro struktury vytvořené pomocí 4D v2004 nebo starší. Pokud tato nastavení nevidíte, vaše struktura je novější a vždy se chová v režimu v11, takže můžete pracovat!

V režimu návrhu použijte volbu Najít pro vyhledávání QUERY BY FORMULA. Protože vaše struktura je v „pomalém“ režimu v2004, měl by být seznam krátký. Dvakrát klikněte na každý výsledek a zkontrolujte kód.

Pokud vzorec používá konstanty, jako např:

QUERY BY FORMULA([Table_2];[Table_1]Field_2="1").

Nebo

QUERY BY FORMULA([Table_2];[Table_1]Field_2=$var) // similar for var or <>var

Vše je v pořádku, není co řešit. Aplikace 4D Remote bude interpretovat proměnnou a odesílat její obsah na server (podobně jako konstantu). Vždy se použije hodnota klienta, i když dotaz provede server.

Pokud je vzorec metodou, jako např:

QUERY BY FORMULA([Table_2];RunQuery)

Je třeba otevřít a zkontrolovat obsah metody. Pokud jsou metodě předávány parametry, je vysoká pravděpodobnost, že metoda je obecná (ale i tak byste ji měli zkontrolovat). Pokud nejsou předány žádné parametry, je vysoká šance, že metoda selže.

Představte si, že metoda RunQuery obsahuje:

$0:= ([Table_2]=myvar)

Obsah myvar se bude lišit na 4D Remote a 4D Serveru, takže spuštění této metody na 4D Serveru selže. Vrátí jiné výsledky.

Existují dva způsoby, jak tento problém vyřešit. Pro jednoduché dotazy, jako je výše uvedený, můžete jednoduše přepsat metodu jako RunQuery(myvar) a uvnitř metody použít $1. Problém vyřešen.

Možná ale narazíte na opravdu složitou metodu. Tisíce řádků kódu, žádná dokumentace, napsaná před 20 lety. A používá se jen jednou za rok. To je spousta práce a riziko chyb za minimální dopad. Chcete-li tento problém obejít, můžete se rozhodnout, že tento kód budete spouštět pouze v režimu v2004, zatímco vše ostatní ponecháte v moderním režimu:

SET DATABASE PARAMETER(Query by formula on server;1)
QUERY BY FORMULA ([Table_2];RunQuery )
SET DATABASE PARAMETER (Query by formula on server;0)

SET DATABASE PARAMETER umožňuje měnit režim za běhu, čímž se vyhnete nutnosti strávit hodiny nad zřídka používaným kódem.

Nakonec byste měli zkontrolovat, zda se pole nepoužívají způsobem, který poškozuje funkci join. Ve verzi v2004 je vzorec jako [Table_1]Field_2=[Table_2]Field_3 interpretován jako hledání statického/fixního obsahu, přičemž se použije obsah pole Field_3. Po zapnutí volby „QUERY BY FORMULA Uses SQL Joins“ je tento příkaz interpretován jako spojení.

Je tedy třeba zkontrolovat každý QBF, zda nepoužívá název pole na pravé straně operátoru „=“. Pokud ano, přiřaďte jej do místní proměnné a v dotazu použijte místní proměnnou.

Po zkontrolování všech výskytů kódu QUERY BY FORMULA, jste připraveni povolit obě možnosti.

Užijte si rychlé vyhledávání…

Thomas Maul
• VP pro strategii, produktové řady 4D • Když byla v roce 1988 vytvořena německá pobočka 4D, Thomas nastoupil do společnosti jako technický ředitel a pomohl vybudovat komunitu 4D vývojářů v Německu i Rakousku. Po mnoha letech podpory zákazníků s technickými problémy a stále větší angažovanosti v otázkách prodeje a managementu byl v roce 1999 povýšen na výkonného ředitele pro 4D Germany. Od roku 2005 se jako člen výkonné rady stal součástí celosvětové strategie společnosti, což vedlo k jeho současné pozici viceprezidenta pro strategii, produktové řady 4D, zodpovědného za definování a realizaci celkové strategie pro produktovou řadu 4D ve vztahu k týmům programování, výzkumu a vývoje, prodeje a marketingu.