Pierwsza z nich polega na przeniesieniu całej konfiguracji cache'owania do osobnej klasy. Chcąc sprawić, aby wyniki zapytania zostały zapamiętane, po prostu tworzylibyśmy sobie taki obiekt i przypisywali do klasy OPD, a ona robiłaby resztę. Naturalnie nacisk zostałby tu położony na wielokrotne wykorzystanie takiego raz stworzonego obiektu, gdyż inaczej w moim odczuciu robić będziemy sztukę dla sztuki. Zalety takiego rozwiązania ujawnią się przy korzystaniu z metody prepare(). Obecnie należy "tuż przed" być pewnym, ile razy później skorzystamy z execute() oraz jakie identyfikatory zostaną przypisane. Wyrzucenie tego do nowej klasy pozwoli na dynamiczne konfigurowanie procesu już w trakcie jego trwania lub składanie go po kawałku bez wpływu na inne wykonywane zapytania.
Drugi pomysł polega na udostępnieniu klasy zwanej "strażnikiem". Jej zadanie jest proste: odpowiednie blokowanie oraz odblokowywanie tabel. Aktualna, "ręczna" realizacja wszystkiego poprzez wywołanie exec() ma taką wadę, iż zupełnie nie uwzględnia ona cache'owania. Ktoś powie, że przesadzam, ale już miałem sytuację, że dodawanie rekordu jest robione tylko wtedy, kiedy fraza X jest zgodna ze wzorcem pobieranym z drugiej tabeli, cache'owanej. Oczywiście blokada być musi, ale z drugiej strony po co ją zakładać, kiedy wyniki są scache'owane, a fraza nie pasuje, ergo - nie wykonujemy dodawania? W zasadzie robimy zbędny LOCK i UNLOCK.
Odnośnie całego projektu Open Power XXX mam jeszcze jedną uwagę, a właściwie prośbę o przypomnienie sobie, iż posiada on własne forum. Zawczasu mówię, iż nie życzę sobie przysyłania mi TUTAJ, na tym blogu błędów, propozycji itd. Wspomnienie o nich, jak i samą dyskusję, można przeprowadzić tam, a przy tym jest o wiele większa szansa, że będę o tym pamiętać, zasiadając ostatecznie do kodu. Mam lepsze rzeczy do roboty, niż uganianie się po kilku megabajtach różnotematycznych wpisów w celu odnalezienia, kto mi co gdzie kiedy pisał.
