acumatica
Acumatica BQL Reference

Analizuj i weryfikuj BQL

Każdy programista aplikacji Acumatica spędza dużo czasu na pisaniu kodu BQL. Jednocześnie nie wszyscy znają podstawowe szczegóły działania typów BQL pod maską.

W sercu BQL leżą dwie kluczowe metody: Parse() i Verify() , zadeklarowane przez interfejs IBqlCreator . Większość powszechnie używanych typów BQL, takich jak Where<> , And<> , Or<> itd., Pochodzi z tego interfejsu.

Należy przyznać, że nazwy, którymi historycznie utknęły te metody, nie są zbyt opisowe. Zapewne lepiej alternatywne nazwy dla nich byłoby PrepareCommandText i Evaluate .

Analizować

public void Parse(
    PXGraph graph, 
    List<IBqlParameter> pars, 
    List<Type> tables, 
    List<Type> fields, 
    List<IBqlSortColumn> sortColumns, 
    StringBuilder text, 
    BqlCommand.Selection selection)

Jedynym celem Parse() jest przetłumaczenie BQL na polecenie SQL, które zostanie wysłane do DBMS. Dlatego ta metoda akceptuje parametr StringBuilder reprezentujący aktualnie budowane polecenie SQL, do którego twórca BQL dołącza własną reprezentację tekstu SQL.

Na przykład metoda Parse() predykatu And<> doda " AND " do tekstu polecenia i rekurencyjnie zażąda tłumaczenia wszystkich zagnieżdżonych twórców BQL.

W szczególności And<ARRegister.docType, Equal<ARDocType.invoice>> przełoży się na coś w rodzaju "AND "ARRegister.DocType = 'AR'" .

Zweryfikować

public void Verify(
    PXCache cache, 
    object item, 
    List<object> pars, 
    ref bool? result, 
    ref object value)

W przeciwieństwie do Parse() , Verify() działa wyłącznie na poziomie aplikacji.

Biorąc pod uwagę rekord (np. Obiekt ARRegister ), można go użyć do obliczenia na nim wyrażeń, w tym do obliczania formuł i oceny warunków.

Parametr result służy do przechowywania wyniku oceny stanu logicznego. Jest używany głównie przez twórców predykcyjnych BQL, takich jak Where<> .

Parametr value służy do przechowywania wyniku obliczenia wyrażenia. Na przykład value Constant<string> BQL Constant<string> jest ciągiem reprezentującym tę stałą.

Przez większość czasu twórcy BQL albo wpływają na wynik, albo na wartość, ale rzadko oba.

Jednym z godnych uwagi zastosowań metody Verify() jest statyczna BqlCommand.Meet() , używana przez PXCache celu ustalenia, czy dany element spełnia polecenie BQL:

public bool Meet(PXCache cache, object item, params object[] parameters)
{
    List<object> pars = new List<object>(parameters);
    bool? result = null;
    object value = null;
    try {
        Verify(cache, item, pars, ref result, ref value);
    }
    catch (SystemException ex) {
        throw new PXException(String.Format("BQL verification failed! {0}", this.ToString()), ex);
    }
    return result == null || result == true;
}

Wniosek

Prawdziwa moc i piękno twórców BQL polega na tym, że większość z nich może być używana zarówno na poziomie bazy danych, jak i aplikacji, umożliwiając mechanizm scalania pamięci podręcznej Acumatica i zapewniając doskonałą okazję do ponownego użycia kodu.

Na przykład po wybraniu rekordów z bazy danych klauzula Where<> polecenia BQL:

• Zapewni Parse() do przetłumaczenia się na tekst SQL podczas przygotowywania poleceń.
• Zapewni Verify() podczas scalania pamięci podręcznej, aby ustalić, które elementy już znajdują się w pamięci podręcznej Meet() warunki klauzuli Where<> , aby uwzględnić takie buforowane elementy w zestawie wyników.