Jedna z důležitých věcí, kterou musíte při programování v Salesforce vést v patrnosti, jsou Governor limity. Typicky se jedná o to, jak dlouho může kód běžet, kolik dotazů do databáze v něm může být a kolika řádků se takové dotazy mohou maximálně týkat. Většinou to i dává smysl a celkem chápete, proč to mají. Občas vám to ale smysl úplně nedává.
Maximálně 100 dotazů na databázi
Napsat dotaz, který například v cyklu prochází jednotlivé záznamy firem a k nim dohledává osoby, se nedělá. Udělá se to hezky tak, že nejdřív v jednom cyklu si do proměnné přiřadíte ID všech firem, které vás zajímají, pak spustíte SOQL dotaz a pak v dalším cyklu projedete výsledky. Pokud na základě výsledků chcete spustit ještě další dotaz (třeba proto, že JOIN v SOQL vlastně neexistuje), tak máte další cyklus a pak ještě jeden hromadný dotaz do databáze.
Což asi dává smysl, než zahltit databázi kupou dotazů je lepší spotřebovat trochu víc paměti na držení těch proměnných, které se poté použijí pro hledání.
Maximálně 50 000 vrácených záznamů
Máte v databázi statisíce záznamů a chcete je všechny projet a něco s nimi udělat? Vytvořte si batch, díky kterému SF hezky rozkouskuje volání do databáze standardně po 200 záznamech, maximálně po 2000.
To dává z hlediska SF velký smysl, vznikne mu sice ohromné množství jednotlivých úloh, ale ty může v rámci zatížení různě pozastavit a servery mu nekleknou.
Srovnejte se s průměrem
Pokud ty předchozí body dávaly smysl, tak dojdete do okamžiku, kdy vám to smysl dávat nebude. Typicky když vás třeba zajímá, jaká je celková průměrná výše daru osob a zda jednotlivé kontakty dávají více nebo méně.
V SQL je to jeden UPDATE s vnořeným SELECT příkazem, něco jako
UPDATE Contact SET AvgPos = (SELECT AVG( Amount)FROM Transactions GROUP BY ContactId) WHERE Contact.Id = Transactions.ContactId)
(znalci SQL mě opraví, ale nemělo by to být nic komplikovaného).
V Salesforce vám začne legrace, při které se vůbec nesmíte spolehnout na sílu a rychlost databáze.
Nejdřív první batch, u kterého nesmíte zapomenout na parametr Database.Stateful, protože normálně ty jednotlivé batche, které SF spouští, o sobě vzájemně neví.
V rámci této dávky si hezky v cyklu projedete všechny záznamy a sami si spočtete, kolik je tedy ta průměrná výše daru.
Až doběhne poslední batch, tak v rámci finish metody spustíte další dávku s parametrem udávajícím to číslo, které jste právě zjistili. A tahle dávka se zase rozprskne do tisíců malých dávek a v dalším cyklu aktualizuje jednotlivé osoby.
SELECT * FROM Contact
Ještě jedna věc v Salesforce vlastně nejde – vrátit hodnotu všech polí. Na začátku vám přijde, že SF je geniální, protože objekt si načtete voláním SOQL příkazu:
Contact[] kontakt = [ SELECT Id, FirstName, LastName from Contact WHERE MailingCity=’Praha‘]
Tohle je prostě super, v Lotus Notes jsme si nejdřív museli nastavovat session, pak databázi, pohled, pak kolekci dokumentů a pak to projíždět, tady to mám v jednom.
Hloupé ovšem je, že ten kontakt, který se vám vrátí, má k dispozici jenom ta pole, na která jste se zeptali. Chcete nastavit jiné? Musíte upravit SOQL dotaz. Chcete záznam zduplikovat a mít v něm všechna pole? Musíte je hezky ručně vypsat (a nezapomenout dotaz upravit, pokud stvoříte pole nová). Jasně, existují na to udělátka, jak projít definici objektu a dotaz seskládat automaticky tak, aby zahrnoval všechna pole, ale to už je ohýbání stavu věcí.
Občas je to programování v Salesforce fakt neskutečná pruda, občas velmi radostná záležitost. Co bude převládat? A podle článku Brada Edgerlyho je nutné na tyto limity myslet i při návrhu Flow (vizuálním „programování“)