Wprowadzenie
Poszczególni producenci używają w komunikacji z bazami danych różnych interfejsów lub różnych dialektów języka SQL. Aby tę komunikację ujednolicić zaimplementowano język Object Query Language (OQL) bazujący na modelu obiektowym i relacyjnym. OQL jest oparty na standardzie SQL. OQL jest wspierany, w podobnym zakresie funkcjonowania jak SQL, dla wszystkich wymienionych tu systemów zarządzania bazami danych. Przy jego tłumaczeniu charakterystyczne nazwy dla Comarch ERP Enterprise zostają przekształcane w techniczne nazwy baz danych, zgodnie z założeniami przestrzeni nazw. Przez to powstają unikalne odniesienia do obiektów, a niezgodności nazw w systemie zostają wykluczone.
Object Manager zapewnia deweloperowi aplikacji prosty sposób dostępu do danych. Zapewnia on indywidualne operacje odczytu, wstawiania, zmiany i usuwania obiektów biznesowych. Ponadto programista aplikacji może używać zapytań OQL w celu jednoczesnego przetwarzania wielu instancji obiektów biznesowych. OQL i Object Manager tworzą interfejs do baz danych dla twórcy aplikacji. Oba korzystają wewnętrznie z niezależnego od platformy protokołu JDBC™. Różne sterowniki JDBC™ są zwykle dostarczane z dodatkowymi parametrami specyficznymi dla producenta, z których niektóre są używane przez Comarch ERP Enterprise w celu skorzystania ze specjalnych funkcji systemów zarządzania bazami danych i wykorzystania potencjalnego wzrostu wydajności.
Grupa docelowa
- Twórcy aplikacji
- Administratorzy
- Użytkownicy posiadający wiedzę techniczną
Wymagania wstępne
Podstawy znajomości Persistence service Comarch ERP Enterprise, znajomość OQL i SQL.
Konwencje
Składnia Object Query Language (OQL) zostanie wyjaśniona za pomocą diagramów składni. Diagram składni składa się z kilku podstawowych elementów i jest czytany od lewej do prawej i od góry do dołu zgodnie z kierunkiem strzałki. Jeśli elementy mogą pojawić się więcej niż raz w wyrażeniu OQL, strzałka prowadzi z powrotem do odpowiedniego elementu.
Jeśli:
- bloki są z zaokrąglonymi rogami reprezentują proste ciągi znaków
- teksty nie są oznaczone kursywą, symbolizują słowa kluczowe lub operatory języka OQL. W słowach kluczowych nie jest rozróżniana wielkość liter
- bloki są zaokrąglone oraz teksty pisane są kursywą, symbole te reprezentują dane wejściowe użytkownika.
Istnieją następujące symbole tego typu:
| Element | Opis |
| PATH | Oznacza dwa lub więcej elementów ID, każdy oddzielony znakiem „.”. Na przykład struktura nazwy obiektu biznesowego: com.cisag.app.general.obj.Item. |
| ID | Nazwa stosowana dla poszczególnych elementów. W zależności od kontekstu może oznaczać nazwę Business Object, atrybut Business Object lub przestrzeń nazw. Nazwa musi zaczynać się literą, dalej w dowolnej kolejności można używać liter, cyfr lub znaków „_“, „$“ oraz „#“. |
| QUOTEDPATH | Element oznacza ID lub PATH, w podwójnym cudzysłowie. Jeśli nazwa pisana jest jak słowo kluczowe OQL, musi zaczynać się i kończyć podwójnym cudzysłowiem. |
| STRING_LITERAL | Ciąg znaków. Ciąg ten musi zaczynać się i kończyć pojedynczym cudzysłowiem. |
| INTEGER_LITERAL | Liczba całkowita. |
| FLOATINGPOINT_LITERAL | Liczba zmiennoprzecinkowa. |
| EOF | Koniec wyrażenia OQL. |
- kwadratowe bloki oznaczają wyrażenia składniowe, które symbolizują bardziej złożone podwyrażenia.
Opis
OQL oferuje możliwość tworzenia zapytań w celu odczytu określonych danych z bazy danych. Możliwe jest również tworzenie, zmienianie lub usuwanie obiektów biznesowych w bazie danych za pomocą OQL. Menedżer obiektów (com.cisag.pgm.appserver.CisObjectManager) oferuje kilka metod, które między innymi oczekują wyrażenia OQL jako parametru transferowy:
- getObjectIterator
- getResultSet
- getUpdateStatement
Komentarze
Możliwe jest użycie komentarzy w zapytaniu OQL. Mogą one być używane na przykład do dokumentowania instrukcji OQL. Istnieją dwa sposoby określenia komentarza:
- w osobnej linii, która musi zaczynać się od znacznika „–„
- poprzez etykietowanie z początkiem komentarza „/*” i końcem komentarza „*/”.
Zapytania
Istnieją dwa różne sposoby dostępu do danych z Business Objects: Metoda getObjectIterator zwraca iterator z wystąpieniami obiektów biznesowych, a metoda getResultset zwraca kolumny określone w zapytaniu OQL.
Proste zapytanie za pomocą getObjectIterator
Metoda getObjectIterator zwraca iterator instancji obiektów biznesowych określonego typu obiektu biznesowego. W zapytaniu OQL można określić, czy mają zostać zwrócone wszystkie instancje obiektu biznesowego, czy tylko instancje spełniające określone warunki. Składnia zapytania OQL akceptowanego przez tę metodę ma następującą strukturę:
Składnia wyrażenia OQL dla getObjectIterator
Ponieważ metoda getObjectIterator zwraca instancje obiektów biznesowych, w przeciwieństwie do SQL nie może być wyboru atrybutu między słowami kluczowymi SELECT FROM.
PATH
W pozycji dla PATH należy określić żądany obiekt biznesowy za pomocą w pełni kwalifikowanej nazwy, np. com.cisag.app.general.obj.Item.
Dodając słowa kluczowe OQL ACTIVE_TABLE dla aktywnej tabeli bazy danych i CONVERTED_TABLE dla tymczasowej tabeli bazy danych z przekonwertowanymi danymi, można określić, z której tabeli dane są odczytywane.
Dane są odczytywane z tabeli, do której pasują załadowane mappery obiektów biznesowych serwera aplikacji.
SELECT FROM com.cisag.app.general.obj.Item ACTIVE_TABLE o
ID
Obiekt biznesowy zawarty w PATH musi posiadać alias, który musi zaczynać się od litery, a następnie może zawierać litery, cyfry i znaki „_”, „$”, „#”.
QUOTEDPATH
Element składni QUOTEDPATH oznacza elementy typu PATH lub ID, które są zapisane między podwójnymi cudzysłowami. Atrybuty obiektów biznesowych mogą mieć taką samą nazwę co słowo kluczowe OQL. W takim przypadku atrybuty w wyrażeniu OQL muszą być ujęte w podwójne cudzysłowy.
SELECT FROM com.cisag.app.general.obj.Boxy bo
WHERE bo: "select" IS NOT NULL
SELECT FROM com.cisag.app.general.obj.Item "SELECT"
W celu zapewnienia przejrzystości nie należy używać słów kluczowych OQL jako aliasów.
Pozostałe elementy składni nie są obowiązkowe. Z wykorzystaniem dotychczas opisanych elementów są możliwe wszystkie zapytania o wystąpienia Business Object.
SELECT FROM com.cisag.app.general.obj.Item item
WHERE LogExpression
Można zawęzić ilość instacji w itaratorze za pomocą słowa kluczowego WHERE i następnie warunku. Element LogEx-pression ma następującą strukturę:
Możliwe jest określenie kilku warunków, które są logicznie powiązane za pomocą słów kluczowych: NOT, AND i OR.
CompareExpr
CompareExpr ma następującą strukturę:
Symbol CompareExpr oznacza trzy podwyrażenia.
IsClause
IsClause może być użyty do sprawdzenia, czy atrybuty obiektu biznesowego mają wartość zero lub różną od zera:
SELECT FROM com.cisag.app.general.obj.Item item
WHERE item:originalItem IS NULL
AttributeRef
Element AttributeRef opisuje, w jaki sposób atrybut obiektu biznesowego jest adresowany w OQL.
Pierwszy element ID oznacza alias obiektu biznesowego z części FROM zapytania. Wybrany atrybut jest nazywany po dwukropku.
W najprostszym przypadku nazwa atrybutu jest zapisywana w miejscu elementu ID.
SELECT FROM com.cisag.app.general.obj.Item item
WHERE item:originalItem IS NOT NULL
Jeśli wybrany atrybut jest częścią Part, pełna ścieżka do atrybutu musi być określona w pozycji elementu PATH. Nazwa atrybutu części może być użyta jako wartość logiczna w celu sprawdzenia, czy atrybut Part ma wartość null. Jeśli atrybut części nie ma wartości null, wartość logiczna ma wartość TRUE.
SELECT FROM com.cisag.app.general.obj.Item item
WHERE item:intrastat=TRUE
AND item:intrastat.indexOfGoodsNumber IS NULL
Jeśli wybrany atrybut jest atrybutem tablicy, żądany indeks musi być określony w nawiasach kwadratowych.
SELECT FROM com.cisag.app.inventory.obj.InventoryItem item
WHERE item:uom[2] IS NOT NULL
Jeśli atrybut tablicy jest typu Part, atrybut Part jest adresowany w następujący sposób:
SELECT FROM com.cisag.app.inventory.obj.InventoryItem item
WHERE item:uomConversionFactor[0].denominator IS NOT NULL
ExistsClause
ExistsClause zwraca true, jeśli SubSelect zwraca wartość, a false – jeśli nie zwraca wartości.
SubSelect jest wyrażeniem select o składni oczekiwanej przez metodę getResultSet.
TermExpr
Element składni TermExpr oznacza podzapytanie OQL, w którym elementy składni Term mogą być połączone z operatorami arytmetycznymi. Operatory arytmetyczne +, -, *, / są obsługiwane w ich zwykłym znaczeniu.
Term
Podzapytanie OQL Term oznacza następujące zapytanie OQL:
Literal
Słowa kluczowe:
- TRUE i FALSE mają swoje zwykłe znaczenie.
- ZEROGUID oznacza identyfikator GUID składający się z zer.
Funkcja TOGUID konwertuje STRING_LITERAL zapisany w nawiasach na GUID. Pozostałe elementy odnoszą się do czasu i daty i zostały opisane rozdziale Funkcje znacznika czasu i daty.
Function
Struktura elementu składni Function
Słowa kluczowe AVG, MAX, MIN, SUM i COUNT są funkcjami agregującymi o takim samym znaczeniu jak w SQL.
Element składni UPPER zapisuje wynik wyrażenia TermExpr wielkimi literami.
SYSTEMTIME
Wyrażenie SYSTEMTIME zwraca bieżący czas systemowy serwera bazy danych.
Element składni „?”
Znak zapytania (?) służy jako symbol zastępczy dla wyrażeń podrzędnych, które są znane tylko w czasie wykonywania. Klasa CisObjectIterator ma kilka metod, za pomocą których symbole „?” są zastępowane wartościami. Zapytanie OQL może zawierać kilka symboli ?. Do metod zmieniających symbol na wartości należy każdorazowo podać pozycję. Symbole są numerowane w porządku rosnącym, począwszy od 1.
byte[] uomGuid = ... ;
CisObjectIterator iter = om.getObjectIterator(
"SELECT FROM com.cisag.app.general.obj.Item i WHERE i:uom=?");
iter.setGuid(1, uomGuid);/
LikeClause
Warunek LIKE służy do prostego dopasowywania wzorców między ciągami znaków.
W języku SQL, można używać znaków % i _. Znak % oznacza dowolny ciąg składający się z dowolnej liczby znaków. Podkreślenie _ oznacza dokładnie jeden znak.
SELECT FROM com.cisag.app.general.obj.Item item
WHERE item:description like 'F%'
Metoda setString klasy CisObjectIterator może być również użyta do przekazania obliczonej wartości do zapytania w celu dopasowania wzorca w czasie wykonywania:
String pattern = '%Screw%';
CisObjectIterator iter = om.getObjectIterator(
"SELECT FROM com.cisag.app.general.obj.Item i WHERE i:description like ?");
iter.setString(1, pattern);
InClause
InClause służy do uzyskiwania tylko tych instancji obiektów biznesowych, których atrybut wcześniej zdefiniowany w wyrażeniu (pozycja TermExpr) pasuje do wartości z listy wartości określonych w nawiasach.
Istnieją dwie opcje określania listy wartości w nawiasach: SubSelect (składnia odpowiada getResultSet) oznacza wyrażenie SELECT, za pomocą którego określane są wartości. Druga opcja oznacza listę TermExpr oddzieloną przecinkami.
String pattern1=...;
String pattern2=...;
CisObjectIterator iter = om.getObjectIterator(
"SELECT FROM com.cisag.app.general.obj.Item i
WHERE i:description IN (?,?)");
iter.setString(1, pattern1);
iter.setString(2,pattern2);
BetweenClause
BetweenClause służy do określania tylko tych obiektów biznesowych, dla których wartości atrybutów zdefiniowanych wcześniej w TermExpr mieszczą się w określonym zakresie wartości (lub nie mieszczą się w przypadku użycia NOT). Granice zakresu wartości są definiowane za pomocą elementu składni TermExpr.
CompareOpExpr
Operatory porównania =, <>, >, <, >=, <= mają takie samo znaczenie jak w SQL.
ORDER BY
Podobnie jak w SQL, OQL oferuje również opcję sortowania zestawu wyników.
Po słowach kluczowych ORDER BY, wymienione są atrybuty do posortowania, oddzielone przecinkami. Po każdym atrybucie na liście można opcjonalnie określić, czy atrybut ma być sortowany w porządku rosnącym (ASC) czy malejącym (DESC). Jeśli nie określono kolejności sortowania, lista jest sortowana w kolejności malejącej.
SELECT FROM com.cisag.app.general.obj.Item item
ORDER BY item:description
Poniższe zapytanie ma takie samo znaczenie:
SELECT FROM com.cisag.app.general.obj.Item item
ORDER BY item:description ASC
Zapytania za pomocą getResultSet
Metoda getResultSet zwraca obiekt typu com.cisag.pgm.appserver.CisResultSet. Atrybuty określone w OQL można tutaj odczytać z jednego lub więcej obiektów biznesowych. Składnia zapytania OQL akceptowanego przez tę metodę ma następującą strukturę:
Wybór atrybutu
Pomiędzy słowami kluczowymi SELECT i FROM musi być wybrany jeden lub więcej atrybutów. Opcjonalnie, słowo kluczowe DISTINCT może wystąpić po SELECT. Gwarantuje to, że po wybraniu atrybutów, które mogą mieć tę samą wartość kilka razy w tabeli, pojawią się one tylko raz na liście wyników. Jeśli zapytanie ma dotyczyć kilku atrybutów, należy je oddzielić przecinkami. Atrybuty mogą być opcjonalnie oznaczone słowem kluczowym AS, po którym następuje aliasa. Alias atrybutu jest używany w widokach OQL do definiowania nazwy atrybutu kolumny zwrotnej widoku. Alias nie może być używany w zapytaniu OQL.
Object
Po wybraniu atrybutu następuje słowo kluczowe FROM. Żądane tabele są wymienione między słowami kluczowymi FROM i WHERE. W najprostszym przypadku wymagane są tylko atrybuty tabeli.
SELECT item:number, item:description
FROM com.cisag.app.general.obj.Item item
Jeśli nazwy tabel są wymienione oddzielone przecinkami, wykonywane jest cross-join.
Użycie nazw tabel lub join może być ujęte w nawiasach.
JoinClause
Rozróżnia się dwa typy join: połączenie obiektów biznesowych i połączenie dynamicznych obiektów biznesowych.
BusinessObjectJoin
Słowa kluczowe INNER, LEFT, RIGHT, FULL i OUTER mają takie samo znaczenie jak w SQL.
Warunek łączenia musi pojawić się w pozycji elementu składni LogExpression.
SELECT ua:user
FROM com.cisag.app.general.obj.JobAssignment ja
JOIN com.cisag.app.general.obj.UserAssignment ua
ON ja:partner=ua:partner WHERE ja:jobDescription=?
DynamicBusinessObjectJoin
Dynamiczne obiekty biznesowe można łączyć z obiektami biznesowymi za pomocą słowa kluczowego DYNAMIC_OBJECT przed JOIN.
Id występujące bezpośrednio po JOIN musi być nazwą dynamicznego obiektu biznesowego. Id przed ON oznacza alias dynamicznego obiektu biznesowego. Id w nawiasach może opcjonalnie zawierać nazwę atrybutu wielowartościowego. Elementy Id w klauzuli ON oznaczają raz alias dynamicznego obiektu biznesowego i alias obiektu biznesowego, do którego ma zostać dołączony dynamiczny obiekt biznesowy.
SELECT item:number
FROM com.cisag.app.general.obj.Item item
DYNAMIC_OBJECT JOIN EXTItem ei
ON ei=item
Id
Element składni Id oznacza opisane już elementy ID i QUOTEDPATH.
GROUP BY
Funkcje agregujące znane z SQL mogą być używane w klauzuli FROM wyrażenia SELECT. Jeśli klauzula FROM zawiera również atrybuty, które nie są używane w funkcjach agregujących, wówczas atrybuty te muszą znajdować się w klauzuli GROUP BY.
SELECT bo:number,COUNT(bo:amount)
FROM com.cisag.app.general.obj.Boxy bo
GROUP BY bo:number
HAVING
Warunek HAVING jest używany w połączeniu z klauzulą GROUP BY. Warunek HAVING może być użyty do zdefiniowania, że tylko grupy spełniające warunek HAVING powinny pojawić się w wyniku.
SELECT bo:number,COUNT(bo:amount)
FROMcom.cisag.app.general.obj.Boxy bo
GROUP BY bo:number
HAVING COUNT(bo:amount)>10
ORDER BY
Podobnie jak w SQL, możliwe jest również sortowanie zestawu wyników w OQL.
Po słowach kluczowych ORDER BY, są wymieniane atrybuty do posortowania, oddzielone przecinkami. Alternatywnie można sortować według kolumny wyboru atrybutu zamiast odwołania do atrybutu. Kolumna z wyboru atrybutów jest identyfikowana przez jej pozycję (od 1 do n). Można użyć ASC i DESC jak w przypadku iteratora obiektów.
SELECT item:guid, item:description
FROM com.cisag.app.general.obj.Item item
ORDER BY item:description
Poniższe wyrażenie ma takie samo znaczenie:
SELECT item:guid, item:description
FROM com.cisag.app.general.obj.Item item
ORDER BY 2
Modyfikacje
Metoda getUpdateStatement klasy CisObjectManager zwraca obiekt typu CisUpdateStatement i akceptuje wyrażenia DELETE, UPDATE i INSERT.
Podczas korzystania z aktualizacji (UPDATE) należy pamiętać o wpływie na wydajność i spójność danych, które opisano w artykule Persistence service.
Usuwanie obiektów biznesowych za pomocą DELETE
Wyrażenie DELETE usuwa wszystkie instancje obiektu biznesowego lub tylko te instancje, które spełniają określony warunek.
DELETE FROM com.cisag.app.general.obj.Item item
Następne zapytanie usuwa tylko instancje, dla których atrybut originalItem zawiera wpis:
DELETE FROM com.cisag.app.general.obj.Item item
WHERE item:originalItem IS NOT NULL
Zmiana obiektów biznesowych za pomocą UPDATE
Wyrażenie UPDATE służy do zmiany wartości atrybutów instancji obiektów biznesowych. Możliwa jest zmiana wszystkich instancji lub ograniczenie liczby instancji do zmiany za pomocą warunku WHERE.
CisUpdateStatement up=om.getUpdateStatement("
UPDATE com.cisag.app.general.obj.Partner partner
SET part-ner:name=?
WHERE partner:guid=?");
up.setString(1,...);
up.setGuid(2,...);
Tworzenie nowych obiektów biznesowych za pomocą INSERT
Nowe instancje obiektów biznesowych można tworzyć za pomocą wyrażenia INSERT.
Po słowach kluczowych INSERT INTO należy podać wybrany obiekt biznesowy dla PATH. Atrybuty, które mają zostać wypełnione wartościami, są następnie podawane w nawiasach. Istnieją dwie opcje określania wartości, które mają zostać przypisane do atrybutów:
- po słowie kluczowym VALUES w nawiasach następuje lista wartości, z których każda jest oddzielona przecinkiem
- wartości są określane za pomocą SubSelect.
CisUpdateStatement up=om.getUpdateStatement("
INSERT INTO com.cisag.app.general.obj.Partner
(guid, number,type,name) VALUES(?,?,?,?)");
up.setGuid(1,...);
up.setString(2,...);
...
Funkcje znacznika czasu i daty
Wyrażenie SYSTEMTIME zwraca bieżący czas serwera bazy danych.
Możliwe jest określenie stałych znacznika czasu lub daty za pomocą funkcji toTimeStamp(). Można to wykorzystać na przykład do klasyfikacji danych.
Aby móc określić prawidłową wartość stałej, należy wziąć pod uwagę typ danych odpowiedniego atrybutu (logiczny typ danych atrybutu). Typy danych znacznika czasu i daty pochodzą ze specjalnie oznaczonych logicznych typów danych, które określają konkretny typ danych atrybutu. Wartości instancji obiektów biznesowych przechowywane dla atrybutu mogą odnosić się do różnych stref czasowych. Należy to również wziąć pod uwagę podczas tworzenia zapytania OQL. Informacje na temat typów danych mozna znaleźć w artykule Typy danych w Comarch ERP Enterprise.
Strefa czasowa musi być określona poprzez jej identyfikację, a nie poprzez skrót zależny od języka. W aplikacji Strefy czasowe znajduje się tabela stref czasowych z nazwami technicznymi i ich opisem. W przypadku strefy czasowej używanej w bieżącej sesji identyfikacja strefy czasowej jest wyświetlana na pasku stanu.
SYSTEMTIME
Wyrażenie SYSTEMTIME umożliwia porównywanie kolumn typu Timestamp z bieżącym czasem serwera bazy danych. Na przykład można wyszukiwać rekordy danych z datą przed lub po bieżącym czasie. Poniższe zapytanie OQL określa wersje artykułów, które staną się ważne dopiero w przyszłości.
SELECT o: "number", o: "validFrom"
FROM com.cisag.app.general.obj.Item o
WHERE o: "validFrom" > SYSTEMTIME
Funkcja toTimeStamp()
Funkcja toTimeStamp() może być użyta do określenia stałej znacznika czasu.
Typy danych daty w Comarch ERP Enterprise są również mapowane na znaczniki czasu w bazie danych. W związku z tym można również określić stałe daty za pomocą tej funkcji.
Funkcja ma następującą sygnaturę:
toTimeStamp(’Timezone ID’, rok, miesiąc, dzień, godziny, minuty, sekundy, milisekundy)
Parametr Timezone ID (ID strefy czasowej) określa, do której strefy czasowej odnosi się określona data i godzina. Określona wartość jest konwertowana na odpowiednią wartość w strefie czasowej GMT dla wyniku zapytania SQL. Wszystkie znaczniki czasu w bazie danych są przechowywane w strefie czasowej GMT. Dlatego należy upewnić się, że używana jest prawidłowa strefa czasowa dla określonej wartości, tak aby żądana wartość odnosząca się do strefy czasowej GMT była faktycznie używana w instrukcji SQL. W przeciwnym razie w instrukcji SQL zostanie użyty nieprawidłowy znacznik czasu, co może prowadzić do nieoczekiwanych wyników.
Określanie stałych znacznika czasu
Można określić żądaną wartość bezpośrednio dla typów danych znacznika czasu Comarch ERP Enterprise.
toTimeStamp(’CET’, 2024, 8, 12, 8, 21,6, 233)
Określanie stałych daty
Aby określić stałe daty, muszą być spełnione pewne warunki systemu typu daty. Wartość daty zawsze ma znormalizowany czas „00:00:00.000” i jest przechowywana w bazie danych jako znacznik czasu. Godzina nie jest zwykle wyświetlana. Aby określić stałą daty, należy użyć tego znormalizowanego czasu.
toTimeStamp(’CET’, 2024, 11, 9, 0, 0, 0)
Jeśli typem danych Comarch ERP Enterprise odpowiedniego atrybutu jest data lokalna, należy pamiętać, że wartość faktycznie przechowywana w bazie danych jest przesunięta o jeden dzień kalendarzowy. Należy zatem dodać dzień kalendarzowy do żądanej wartości.
toTimeStamp(’CET’, 2024, 11, 10, 0, 0, 0, 0)
Odtwarzanie wyszukiwania
Aby odtworzyć takie samo zachowanie, jak w przypadku wyszukiwania na atrybucie typu „data lokalna”, należy określić przedział, w którym mogą znajdować się znaczniki czasu dla wybranej daty. Wyszukiwanie wykorzystuje przedział od poprzedniego dnia kalendarzowego z czasem „12:00:00.000” do określonej daty z czasem „11:59:59.999”. Spowoduje to znalezienie dowolnej wartości daty, która pokrywa się z określonym zakresem dat o co najmniej 12 godzin.
...
WHERE ... dateAttr >= toTimeStamp('CET', 2024, 11, 8, 12, 0, 0, 0)
AND dateAttr < toTimeStamp('CET', 2024, 11, 9, 12, 0, 0, 0) ....
W przypadku atrybutu typu local to-date podczas tworzenia przedziału należy uwzględnić przesunięcie o jeden dzień kalendarzowy.
Stałe znacznika czasu
Istotne stałe znaczników czasu są udostępniane za pomocą następujących stałych OQL:
| Nazwa stałej OQL | Znaczenie |
| UNDEFINED_TIME_STAMP | Znacznik czasu zapisywany na bazie danych dla niezdefiniowanej wartości. |
| MIN_TIME_STAMP | Najmniejszy znacznik czasu, który może być zapisany na bazie danych |
| MAX_TIME_STAMP | Największy znacznik czasu, który może być zapisany na bazie danych |
Funkcja toTimeZoneGuid()
Funkcji pozwala na określenie identyfikatora GUID strefy czasowej w celu identyfikacji strefy czasowej. Umożliwia to na przykład wybranie wartości znacznika czasu lub daty z określonych stref czasowych.
Funkcja ma następującą sygnaturę:
toTimeZoneGuid(’Identyfikator strefy czasowej’)
toTimeZoneGuid('CET')
Rozszerzenia składni OQL dla obiektu deweloperskiego Search
Za pomocą obiektu deweloperskiego Search można zdefiniować wyszukiwanie do zastosowania na modyfikowalnych listach. Części zapytania OQL, takie jak klauzula FROM, muszą być określone w celu opisania wyniku zapytania. W tym celu można użyć specjalnych elementów składni OQL, które są dozwolone tylko w definicji wyszukiwania.
Optymalizacja złączeń (Join) zapytania OQL
W zapytaniu OQL zwykle definiuje się kilka połączeń z obiektami biznesowymi, których jedynym celem jest rozszerzenie zestawu kolumn do wyboru, wyświetlania i sortowania. W zależności od konkretnego zapytania wyszukiwania, niektóre z tych łączeń (join) mogą nie mieć wpływu na wynik wyszukiwania. Takie join są automatycznie rozpoznawane i usuwane przed wykonaniem instrukcji OQL w celu zwiększenia wydajności wykonania.
Jeśli atrybuty „połączonego” obiektu biznesowego są używane tylko w klauzuli SELECT, połączenie to można również usunąć z zapytania OQL pod pewnymi warunkami. W takim przypadku wymagane wartości atrybutów są określane za pośrednictwem Persistence service przy użyciu współdzielonej pamięci podręcznej. Jednak wartości określone w ten sposób nie muszą już odpowiadać wartościom w bazie danych, np. zawartość pamięci podręcznej była nieaktualna w momencie zapytania. Oznaczając połączenie słowem kluczowym REMOVABLE, następuje określenie, ze połączenie może zostać usunięte przez system podczas wyszukiwania w celu zwiększenia wydajności, ale także, że dane określone za pośrednictwem Persistence service mogą być niezgodne z rzeczywistą zawartością bazy danych (nie są bezpieczne dla transakcji). Bezpieczeństwo transakcji nie jest jednak zasadniczo wymagane do wyświetlania danych na listach lub wyszukiwaniach.
Dołączony obiekt biznesowy musi spełniać następujące warunki, aby można go było usunąć z instrukcji OQL:
- typ złączenia to LEFT OUTER lub RIGHT OUTER
- żadne atrybuty połączonego obiektu biznesowego nie są używane w klauzulach WHERE, ORDER BY, GROUP BY lub HAVING. Jeśli atrybuty połączonego obiektu biznesowego są używane w klauzuli SELECT, połączenie musi być wyraźnie oznaczone słowem kluczowym REMOVABLE.
- warunek join musi być zdefiniowany dla wszystkich atrybutów klucza połączonego obiektu biznesowego w postaci „atrybut klucza obcego1 = atrybut klucza1 AND atrybut klucza obcego2 = atrybut klucza2 AND …” i nie może zawierać żadnych innych warunków. Jeśli atrybut validFrom nie został określony w klauzuli ON dla obiektu biznesowego zależnego od czasu, jest on domyślnie brany pod uwagę tak jak poprzednio.
- inne join, które odnoszą się do innego połączenia (join), które ma zostać usunięte w ich klauzuli ON, również muszą być możliwe do usunięcia.
SELECT p:number, l:isoCode
FROM com.cisag.app.general.obj.Partner p
REMOVABLE LEFT OUTER JOIN com.cisag.app.general.obj.Language l on p:language = l:guid
staje się wewnętrznym zapytaniem OQL
SELECT p:number, p:language
FROM com.cisag.app.general.obj.Partner p
która jest wykonywana w bazie danych. W przypadku zapytania l:isoCode z zestawu wyników, klucz Persistence service jest generowany za pośrednictwem wartości atrybutu p:language, powiązana instancja języka jest ładowana za pośrednictwem Persistence service i zwracana jest wartość atrybutu isoCode.
