Słowem wstępu

Jest sobie taki interfejs w php, który się zwie Iterator, posiadający 5 metod, które informują foreach jak sobie ma radzić z argumentami niebędącymi tablicą. On zaś (co jeszcze dziwniejsze) dziedziczy po kolejnym interfejsie który się zwie Travesrable. To co poniżej zobaczycie w pełnej krasie, jest implementacją mapy.
Ale do rzeczy, po cholerę nam takie pyszne rzeczy? Otóż jeżeli chcielibyśmy sobie obiektowo przechowywać elementy w zmiennej nie będącej tablicą i przeiterować jest foreachem, to jak to zrobicie? No to pokaże Wam jak to można było by zrobić:

 
/* odpowiedni foreach dla ($objIt as $key => $value ) */
$objIt = new MyIterator();
for( $objIt->rewind(); $obj->valid(); $objIt->next() ) {
  $key = $objIt->key();
  $member = $objIt->current();
}

Trochę mało to Wam mówi jeszcze, ale jak spojrzycie na dalszą część tekstu to się sami przekonacie.

Klasa Collection

Na omówieniu tej klasy, przysłużę się przykładem z książki.

Pisząc aplikację, często zachodzi potrzeba utworzeniu obiektów, które zawierają w sobie grupę innych obiektów. Na przykład w systemie obsługi dziekanatu potrzebna będzie klasa Student oraz Course. Obiekt Student zapewne będzie miał przypisany więcej niże jeden obiekt Course. Pierwsze nasuwające się rozwiążanie to dodanie tablicy obiektów Course jako zmiennej składowej obiektu Student.

Przykład z książki:

class Student {
  public $courses = array();
  //... itd
}
 
$objStudent = new Student( 124 );
foreach( $objStudent->courses as $objCourse ) {
  print $objCourse->name;
}

I wracamy do omówienia problemu:

Oczywiście gdyby taki sposób był najlepszy, to by nie było mowy o klasie Collection (trochę to przerobiłem )

Powyższe rozwiązanie sprawia kilka problemów. Po pierwsze, publiczny dostęp do tablicy obiektów Course nie jest zgodny z zasadą hermetyzacji. Nie ma możliwości weryfikacji zmian w tablicy czy modyfikacji stanu obiektu Student, gdyby zaszła taka potrzeba. Po drugie, taka implementacja nie określa porządku elementów w tablicy ani sposobu odnalezienia poszukiwanego obiektu. Po trzecie, i najważniejsze, aby zapewnić dostęp do informacji o kursach każdemu użytkownikowi klasy Student, informacje te muszą zostać pobrane z bazy danych za każdym razem, gdy pobierane są informacje o studencie. Oznacza to że nawet jeśli konieczne jest jedynie wyświetlenie imienia studenta, pobierane są wszystkie informacje o kursach. Niepotrzebnie zwiększa to obciążenie serwera baz danych i zmniejsza wydajność aplikacji.
Klasa Collection została zaprojektowana tak, aby rozwiązać wszystkie te problemy. Zapewnia obiektową otoczkę dla tablicy i implementuje mechanizm leniwej konkretyzacji, czyli opóźnienia procesu tworzenia elementów kolekcji aż do czasu, gdy są one naprawdę potrzebne. Nazywa się ją „leniwą”, ponieważ decyzja o tym, kiedy tworzyć konkretne egzemplarze obiektów, jest podejmowana przez samą aplikację.

Dobra, o co ogólnie chodzi? Chodzi o to że nasza klasa Collection, jak sama nazwa wskazuje jest kolekcją obiektów, czyli dodajemy do niej obiekty, a ona zgrabnie je przechowuje w swoim ciele. I to by było na tyle z filozofią klasy Collection, żeby zbytnio nie przeciągać, to poniżej mamy już dwie gotowe klasy które razem z sobą współpracują, są na żywca wydarte z mojego FW, także BDT_Loader, jak po samej nazwie można się domyślić, wczytuje klasy, także nie mam tu nic więcej do dodania. Klasa BDT_Collection_Exception jest po prostu klasą wyjątków, i tu też nie mam nic więcej do dodania.
W naszym przykładzie będziemy potrzebowali dwie klasy, Collection (BDT_Collection) oraz CollectionIterator (BDT_Collection_Iterator). Obiekt klasy CollectionIterator jest tworzony w metodzie getIterator. Pod ciałem klasy, krótki opis.

<?php
 
BDT_Loader::loadFile( array(
   './lib/BDT/Collection/BDT_Collection_Iterator.php',
   './lib/BDT/Exception/BDT_Collection_Exception.php'
) );
 
class BDT_Collection implements IteratorAggregate {
 
   private $_members = array();
 
   private $_onload;
 
   private $_isLoaded = false;
 
   public function addItem( $obj, $key = NULL ) {
      $this->_checkCallback();
 
      if( $key ) {
         if( isset( $this->_members[ $key ] ) )
            throw new BDT_Collection_Exception( 'Klucz ' . htmlspecialchars( $key, ENT_QUOTES, 'UTF-8' ) . ' jest już zajęty' );
         else
            $this->_members[ $key ] = $obj;
      } else
         $this->_members[] = $obj;
   }
 
   public function removeItem( $key ) {
      $this->_checkCallback();
 
      if( isset( $this->_members[ $key ] ) )
         unset( $this->_members[ $key ] );
      else
         throw new BDT_Collection_Exception( 'Błędny klucz ' . htmlspecialchars( $key, ENT_QUOTES, 'UTF-8' ) );
   }
 
   public function getItem( $key ) {
      $this->_checkCallback();
 
      if( isset( $this->_members[ $key ] ) )
         return $this->_members[ $key ];
      else
         throw new BDT_Collection_Exception( 'Błędny klucz ' . htmlspecialchars( $key, ENT_QUOTES, 'UTF-8' ) );
   }
 
   public function keys() {
      $this->_checkCallback();
 
      return array_keys( $this->_members );
   }
 
   public function length() {
      $this->_checkCallback();
 
      return count( $this->_members );
   }
 
   public function exists( $key ) {
      $this->_checkCallback();
 
      return isset( $this->_members[ $key ] );
   }
 
   public function getIterator() {
      $this->_checkCallback();
 
      return new BDT_Collection_Iterator( clone $this );
   }
 
   public function setLoadCallback( $functionName, $objOrClass = NULL ) {
      if( $objOrClass )
         $callback = array( $objOrClass, $functionName );
      else
         $callback = $functionName;
 
      if( !is_callable( $callback, false, $callableName ) ) {
         throw new BDT_Collection_Exception( 'Funkcja zwrotna ' . htmlspecialchars( $callableName, ENT_QUOTES, 'UTF-8' ) . ' nieprawidłowa!' );
         return FALSE;
      }
      $this->_onload = $callback;
   }
 
   private function _checkCallback() {
      if( isset( $this->_onload ) && !$this->_isLoaded ) {
         $this->_isLoaded = true;
         call_user_func( $this->_onload, $this );
      }
   }
}

Jak łatwo zauważyć w każdej z metod, sprawdzamy callbacka, czyli funkcje która powinna zostać wywołana przy utworzeniu kolekcji obiektów. Taka funkcja lub metoda może zostać utworzona w ciele klasy, w której wykorzystujemy kolekcje obiektów, lub po prostu jako zwykła funkcja, poniżej będzie przykład.

Klasa CollectionIterator

W tej klasie nie ma co zmieniać, no chyba że nazwy klas, bo metod to nie można, są wymagane przez interfejs który klasa implementuje. To też nie może być klasa abstrakcyjna, gdyż jest tworzony jej obiekt. Klasa jak klasa, przepisać, skopiować, pozmieniać nazwy jak komu się podoba klas, i używać.

<?php
 
class BDT_Collection_Iterator implements Iterator {
   private $_collection;
 
   private $_currIndex = 0;
 
   private $_keys;
 
   public function __construct( BDT_Collection $objCol ) {
      $this->_collection = $objCol;
      $this->_keys = $this->_collection->keys();
   }
 
   public function rewind() {
      $this->_currIndex = 0;
   }
 
   public function key() {
      return $this->_keys[ $this->_currIndex ];
   }
 
   public function current() {
      return $this->_collection->getItem( $this->_keys[ $this->_currIndex ] );
   }
 
   public function next() {
      ++$this->_currIndex;
   }
 
   public function valid() {
      return isset( $this->_keys[ $this->_currIndex ] );
   }
}

Narzucanie wymagań co do kolekcji

Możemy też wymusić na danym obiekcie jakiego typu dana kolekcja musi być, a możemy to zrobić dzięki dziedziczeniu:

<?php
 
class OwnCollection extends BDT_Collection {
  public function addItem( OwnClass $obj, $key = NULL ) {
    parent::addItem( $obj, $key );
  }
}

I dzięki takiemu zastosowaniu, nie tworzymy obiektu BDT_Collection, w swojej klasie, tylko OwnCollection, i obiekty które prześlemy do naszej kolekcji muszą być pochodzenia klasy OwnClass.

Implementacja

Prosty przykład z użyciem callbacka, dla Collection ( z książki ):

<?php
 
class Singer{
  public $name;
 
  public function __construct( $name ) {
    $this->name = $name;
  }
}
 
class NightClub {
  public $name;
  public $singers;
  public function __construct( $name ) {
    $this->name = $name;
    $this->singers = new BDT_Collection;
    $this->singers->setLoadCallback( '_loadSingers', $this );
  }
 
  public function _loadSingers( BDT_Collection $col ) {
    $col->addItem( new Singer( "Maciek" ) );
    $col->addItem( new Singer( "Grzesiek" ) );
    $col->addItem( new Singer( "Wojtek" ) );
}
 
$objNightClub = new NightClub( "Rotunda" );
echo "Witamy w klubie " . $objNightClub->name . "<br />";
echo "Dziś zaśpiewa nam " . $objNightClub->singers->length() . " piosenkarzy <br />";
echo "Oto oni: <br />";
foreach( $objNightClub->singers as $objSinger )
  echo "Piosenkarz " . $objSinger->name ." <br />";
echo "Powitajmy ich gorąco oklaskami";

Słów kilka na zakończenie

Nie mam zbytnio jak tego sprawdzić, gdyż leże chory w łóżku i pisze na dziewczyny laptopie (mój lap też ma chorobowe), a tutaj jest winzgroza, także wybaczcie jak się tam jakieś błędy wtargnęły. Szkic ten ma już trochę czasu, stąd miałem kod z swojego FW. Klasa bardzo przyjemna, można ją w wielu rzeczach zaimplementować, u mnie działa jako kolekcja widoków i slotów w klasie szablonów (templatek), jak się uda to ją zaimplementuje w większej ilości miejsc, bo jest na prawdę ciekawa, chociażby do przechowywania wyników zapytań, przy pobieraniu z bazy danych. Za wszelkie błędy z góry przepraszam, za to że kod prawie żywcem zdarty z książki, nie przepraszam Za to że klasy nie opisane, przepraszam (jak wyzdrowieje to poprawie). Mam nadzieje że nie tylko mi się przyda taka klasa ale i zarówno Wam.

Na zakończenie, dodam że kolega Wojciech Soczyński, też omówił na swoim blogu, implementację interfejsu Iterator. Link poniżej.

Pętle cd.

Miałem napisać o pętlach, w poprzednim wpisie, ale materiał jest na tyle obszerny że postanowiłem to przenieść i poświęcić im cały wpis. No to jedziemy.

Pętle jak nam ładnie pokazuje manual:

[ <<label>> ]
LOOP
    statements
END LOOP [ label ];

Proste co? A teraz, krótki opis, otóż każda pętla może zostać „nazwana”, czyli posiadać tzw. label ( z ang. etykietę ), po co? Po to gdy będziemy chcieli zakończyć pętle, a będziemy mieli zagnieżdżenie pętel, to w przypadku chęci wyjścia całkiem z wszystkich pętli, wystarczy podać nazwę pętli wyżej. Służy nam temu polecenie:

EXIT [ label ] [ WHEN boolean-expression ];

Dlaczego nie RETURN a EXIT? Otóż możemy równie dobrze użyć RETURN w pętli by z niej wyjść, ale słowo kluczowe RETURN mówi nam coś innego, zwróć. A co my zwracamy wychodząc z pętli? No nic, także te słowo jest mylne.

Wracając do pętli, może się dziwnie wydawać że nie wiadomo kiedy się ona skończy, gdyż nie jest podoba do żadnej z pętli znanych nam z języka php, ani to for, ani do … while, ani while itd. No właśnie, gdybyśmy nie mieli żadnego warunku w pętli kończącego ją, to dostalibyśmy pętlę nieskończoną. Dlatego taka pętla musi posiadać w sobie warunek skończenia. Musimy na własną rękę inkrementować (itp..) jakaś wartość i sprawdzać ją w pętli. Otóż samej pętli LOOP to uwierzcie mi lub nie, to rzadko będziecie używać. No jest sama w sobie mało przydatna.

Iteracja tablicy elementów

Definicja pętli:

[ <<label>> ]
FOR name IN [ REVERSE ] expression .. expression [ BY expression ] LOOP
    statements
END LOOP [ label ];

Tu jest moc, ukłony dla dev z postgre za wskaźniki. Dzięki językowi proceduralnemu PL/pgSQL, nie musimy się troszczyć o deklaracje wskaźników w pętli i ich wykorzystywanie, są one automatycznie definiowane i używane przez silnik bazy. Dobre co? W postgresie mamy typy tablicowe. Deklaracja jest bardzo podobna jak w innych językach:

• INT[]
• VARCHAR[]

I tak dalej, dobra dajmy na to że mamy funkcję której jednym z argumentów jest właśnie np VARCHAR[], co lepsze możemy zdefiniować argument funkcji jako ANYARRAY, i dzięki temu, możemy do takiej funkcji przesyłać tablicę różnego typu, bez potrzeby martwienia się o to, w jaki sposób to przesyłamy, i tak później przy wrzucaniu danych do bazy musimy rzutować typ. Wracając do sedna, to mamy taką tablice, która składa się np z 6 elementów. Indeksy tablic w postgresql są numerowane od 1 Też sobie wymyślili, no ale dobra. Mamy taką tablice, i dajmy na to że składa się z 240 wierszy. Czyli jest 240 indeksów. Albo i nie, ponieważ taka tablica może być dynamiczna i w sumie nie wiemy jak wielka jest ta tablica, wiemy jedynie że będzie posiadać 6 elementów jeden wiersz. I jak to zrobić? Patrzcie:

FOR i IN ARRAY_LOWER( "_someVar", 1 ) .. ARRAY_UPPER( "_someVar", 1 )
  LOOP
 
    INSERT INTO
      "someTable"
    (
      ... -- jakieś tam kolumny
    )
    VALUES
    (
      "_someVar"[ i ][ 1 ]::INT,
      "_someVar"[ i ][ 2 ]::VARCHAR,
      "_someVar"[ i ][ 3 ]::BOOLEAN,
      "_someVar"[ i ][ 4 ]::BIT,
      "_someVar"[ i ][ 5 ]::NUMERIC,
      "_someVar"[ i ][ 6 ]::BYTEA,
    );
 
  END LOOP;

Co to jest i ? i jest numerem indeksu, nie musimy go definiować w bloku DECLARE, jest on w biegu definiowany.

Jest moc co? Możemy w tablicy przechowywać różnego typu wartości i później w zależności jakiego typu jest dana kolumna, rzutujemy ją do odpowiedniego typu i jazda.

Napisałem powyżej że pętla musi posiadać w sobie warunek skończenia, no właśnie nie musi Tzn w zależności w jakim kontekście jej użyjemy.

Iteracja wyników zapytania

Definicja pętli:

[ <<label>> ]
FOR target IN query LOOP
    statements
END LOOP [ label ];

Nie opisałem definicji tych dwóch pętli, gdyż na przykładzie pierwszej, analiza dwóch pozostałych w przykładach powinna być dość prosta.

Dość fajna i ciekawa pętla, która dość często się przydaje, o co chodzi? Mamy sytuacje że na podstawie jednego wiersza i argumentów w nim zawartych musimy zmienić inne wiersze. Przeliczyć jakieś wartości czy cokolwiek innego.

FOR "__row" IN
  SELECT
    "someColumn"
  FROM
    "someTable"
  WHERE
    "someOtherColumn" = "someVar" -- nie ma tutaj średnika, ważne!
LOOP
  PERFORM "someFunction"( "__row"."someColumn" );
END LOOP;

A teraz trochę co się tam dzieje i co jest czym. Od początku. Zmienna „__row” jest zdefiniowana jako RECORD w bloku DECLARE. Dzięki takiej definicji możemy wykorzystać ją jako obiekt wiersza w pętli, i obiektowo odwoływać się do kolumn pobranych w zapytaniu poprzez właśnie tą zmienną. Tak jak to widzimy w argumencie funkcji „someFunction”. Normalnie pobieramy sobie dane w select, podajemy warunki, sortujemy, robimy zwykłego selecta. Następnie iterujemy elementy wyniku zapytania, wiersz po wierszu. W moim przykładzie wywołujemy w pętli inną funkcję która coś robi. Równie dobrze na podstawie tych elementów z wyniku zapytania możemy robić inne rzeczy jak np aktualizacja innych wierszy w bazie itd.

W sumie, to by było na tyle jeżeli chodzi o pętle, są inne sposoby tworzenia pętli, ale nigdy mi one nie były potrzebne, nigdy z nich nie korzystałem. Także zachęcam do manuala. Jak zwykle w linkach poniżej.

Słów kilka o wydajności

Jeszcze chciałbym o jednej rzeczy wspomnieć, ponieważ dużo osób upiera się przy stwierdzeniu że założenie przeniesienia logiki aplikacji do sql wcale nie odciąży serwera, po prostu przeniesie środek ciężkości w inne miejsce. Ja się z tym stwierdzeniem nie będę kłócił bo to prawda, i jest jeszcze jedna rzecz która mi nie daje spokoju. Niektórzy z Was twierdzą że funkcje plpgsql będą za bardzo obciążać serwer, pewnie że będą jak się je beznadziejnie napisze.

Bardzo prosty przykład, zwykły warunek (koniunkcja), mamy jakieś dane, i potrafimy stwierdzić że w większości przypadków warunek będzie nieprawdziwy, więc po co w takim razie stawiać ten warunek, który będzie nieprawdziwy na drugim miejscu w koniunkcji? Co innego w alternatywie. Taka prosta rzecz, może szału nie zrobi na prędkości uzyskanej na takiej rzeczy, ale należy o tym pamiętać. Druga rzecz, ilość pamięci wykorzystanej przez funkcje, otóż wiadomą rzeczą jest to że gdy zdefiniujemy masę zmiennych, funkcja napęcznieje, a takie zmienne jak: „__isSelected” czy podobnego typu rzeczy można zastąpić w bardzo prosty sposób. Prosty przykład:

PERFORM
  1
FROM
  "someTable"
WHERE
  "someColumn" = "_someVar";
 
IF NOT FOUND THEN
  .... -- coś robimy gdy nie znaleziono
 
ELSE
  ... -- robimy coś innego
 
END IF;

I teraz kolejny przykład przypadku, gdy będziemy wiedzieć że dany warunek w większości przypadków zostanie spełniono to zastąpimy NOT FOUND, po prostu FOUND, nie ustawiamy żadnych zmiennych, nie nadajemy im wartości, a metoda PERFORM jest o tyle fajna, że nie musimy nigdzie przypisywać wartości zwracanych z tego innego SELCT‘a.

To by było na tyle tego całego wpisu, mam nadzieje że był interesujący.

Założenia do BDT

- W pełni obiektowy
- Podstawowe narzędzia dla developera
- Darmowy na licencji GPL

to by było na tyle

Użyte narzędzia

- Horde Routes
- Cache by MatheW ( linki na dole )
- Laptop, klawiatura, myszka, monitor, trochę palców… własne pomysły + podpatrzone.

Co już mam zrobione

- Obsługa akcji,
- Routing (ta już był tylko zaimplementować),
- Cache (j/w),
- System szablonów ( php + html, żadne smarty opty i inne śmiecie ),
- Obsługa błędów ( wyjątki + trigger_error ),
- Obsługa SQL w 40%,
- Confingi ( w XML )

Czego jeszcze nie mam zrobione

- Requesty (ale mam już koncept)
- Weryfikacja danych (j/w)
- Headery (szczerze, to mi się w to nie chce bawić, oprócz takich podstawowych jak 404 itp)
- MultiLanguage ( dla błędów to będzie na 100% gettext, i l18n dla treści )
- Instalator ( jeszcze nie wiem czy będzie )

Co chcę uzyskać

Chcę napisać wydajny system, który usprawni mi pracę, która sprawi mi jeszcze więcej przyjemności niż Wam się wydaje, gdyż dla mnie programowanie to frajda. Olałem Doctrine, gdyż z tymi pajacami z dev nie można się w żaden sposób dogadać, myślą że pozjadali wszystkie rozumy i są najlepsi na świecie, także ORM będzie trochę inny niż wszystkie. Piszę swój system do zarządzania SQL’em, oczywiście nie będzie tam żadnych INSERT, UPDATE czy DELETE w kodzie wykonanego wszystko będzie oparte o język proceduralny PL/pgSQL nazwałem tą aplikację PGFM (PostgreSQL Function Mapper) … ( przy okazji refaktoryzacji kodu już zdążyłem zmienić nazwy większości klas, także ciekawe co z tego wyjdzie…) . Czyli dodanie rekordów do bazy danych czy ich aktualizacja lub/i usunięcie będzie się wykonywało poprzez procedury. W pewnym stopniu jest to przeniesienie logiki aplikacji do SQL’a, ale dlaczego nie? Jest to ciekawe rozwiązanie i nigdzie wcześniej nie widziałem takiego rozwiązania ( no prawie nigdzie ale nie mogę powiedzieć gdzie ;] domyślcie się gdzie ).

Dlaczego darmowy?

Dlatego że chce by każdy miał dostęp do innego spojrzenia na problem by też mógł się rozwijać analizując czyjś kod, może znajdzie ktoś jakiś błąd i pomoże mi go naprawić. Ale szczerze powiedziawszy nie liczę na to że będziecie chcieli używać tych narzędzi, nie zależy mi na tym. Piszę go dla siebie i dla firmy mojego kolegi

Bezpieczeństwo

Dużą wagę przekładam na bezpieczeństwo aplikacji, zatem data wydania będzie się przeciągać w czasie, będę chciał uniknąć falstartów i śpieszyć się z tym byście ujrzeli moje wypociny, jakoś mi się nie śpieszy. Rdzeń aplikacji będzie a przynajmniej będę miał takie założenie, odporny na taki typu sql injecty, xss’y i masę innych dupereli.

Słów kilka na zakończenie

Pewnie nie jeden z Was zapyta się po co to piszę? No napisałem powyżej, chce to zrobić by zostawić jakiś ślad po sobie. Oraz piszę też to po to by się samemu rozwijać, widzieć problem i znaleźć rozwiązanie dla niego. Na prawdę fajnie się idzie owkurw**** jak coś nie wychodzi, a później olśnienie i tona euforii jak zaczyna działać. To jest właśnie to dlaczego piszę swoją aplikację. Poza tym TAO programowania.

Sortowanie w ltree

Rozwiązanie było bliżej niż można było się tego spodziewać. Miałem z trylion pomysłów jak to rozkminić. Pomyślałem o liczbie rzeczywistej której każda kolejna część po przecinku będzie przedstawiała nr zagłębienia, tylko to nie jest tak łatwo oprogramować i mogłyby wyjść niezłe kaszany, także odpuściłem sobie to. I olśniło mnie ARRAY! No jacha! To przecież jest tak proste i oczywiste że nie wiem o czym my rozmawiamy. Sam sobie ten problem urodziłem, a powodem tego było iż nikt wcześniej nie pisał o tym, w necie to nawet nie ma słowa o tym module, parę rzeczy znajdziemy w manualu i stronie twórców. Ale nikt nie pokwapił się z implementacją tego z sortowaniem i się nie podzielił.

Implementacja ltree z sortowaniem

Otóż sprawa jest banalnie prosta (teraz już jest):

CREATE TABLE "category" (
   "idCategory"  SERIAL PRIMARY KEY NOT NULL,
   "categoryPath"   LTREE,
   "ordering" INT[]
);

I mógłbym powiedzieć amen. Alę dodam jeszcze:

INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top', '{1}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Science', '{1,1}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Science.Astronomy', '{1,1,1}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Science.Astronomy.Astrophysics', '{1,1,1,1}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Science.Astronomy.Cosmology'. '{1,1,1,2}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Science.Astronomy.Planets'. '{1,1,1,3}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies', '{1,2}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies.Amateurs_Astronomy', '{1,2,1}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies.Swiming', '{1,2,2}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies.Football', '{1,2,3}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies.Chess', '{1,2,4}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies.Basketball', '{1,2,5}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies.Voleyball', '{1,2,6}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies.Checkers', '{1,2,7}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies.Cards', '{1,2,8}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies.Skis', '{1,2,9}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies.Post_Cards', '{1,2,10}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies.Book', '{1,2,11}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections', '{1,3}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures', '{1,3,1}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures.Astronomy', '{1,3,1,1}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures.Astronomy.Stars', '{1,3,1,1,1}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures.Astronomy.Galaxies', '{1,3,1,1,2}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures.Astronomy.Astronauts', '{1,3,1,1,3}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures.Astronomy.Planets', '{1,3,1,1,4}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures.Astronomy.Sun', '{1,3,1,1,5}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures.Astronomy.Earth', '{1,3,1,1,6}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures.Astronomy.Asteroids', '{1,3,1,1,7}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures.Astronomy.UFO', '{1,3,1,1,8}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures.Astronomy.Milk_Way', '{1,3,1,1,9}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures.Astronomy.Space_Ships', '{1,3,1,1,10}');

To powyżej to demo do tabeli, o zapomniałbym o indeksach:

CREATE INDEX "categoryPath_gist_idx" ON "category" USING gist( "categoryPath" );
CREATE INDEX "categoryPath_idx" ON "category" USING btree( "categoryPath" );
CREATE INDEX "ordering_gist_idx" ON "category" USING gist( "categoryPath" );
CREATE INDEX "ordering_idx" ON "category" USING btree( "categoryPath" );

I sobie protestujcie sami jak to świetnie działa. W następnym i przy okazji ostatnim wpisie o ltree, przedstawię wszystkie metody do zarządzania drzewem, oraz widoki.

Instrukcje warunkowe

Ten dział będzie poświęcony po prostu warunkom. Otóż jak wyżej wspomniałem w postgresie możemy stosować różnego rodzaju warunki, począwszy od IFów poprzez CASE skończywszy na COALESCE lub nie.
Popatrzmy na przykład użycia IFa w funkcji:

CREATE..... RETURNS VOID AS $BODY$
  BEGIN
    SELECT
      ....
    FROM
      ...
    WHERE ....;
 
    IF NOT FOUND THEN
      -- coś tu robimy jak nie znaleziono
    ELSE
      -- w innym wypadku co innego lub kończymy RETURNem
    END IF;
  END;
$BODY$ LANGUAGE 'plpgsql';

Jak widać składnia IFa jest trochę podobna do tej której znamy z innych języków z tym że tutaj mamy słowo kluczowe THEN, które nie w każdym języku jest (bodajże w pascalu było ale mi się szukać nie chce). Kończywszy IFa musimy użyć składni END IF; Jak widać nie mamy tutaj żadnych klamer, dlatego ważne jest by stosować wcięcia przy kodowaniu by się samemu nie pogubić w zagłębieniach kodu. Taki kod od razu staje się czytelniejszy.

Jak widać dzięki takim rozwiązaniom ograniczymy się do wywołania tylko jednej funkcji z kodu php, dzięki temu i kod staje się czytelniejszy, w ten sposób można przerzucić pewną cześć logiki aplikacji na bazę danych, co w znacznym stopniu ułatwia pracę (ale i też może utrudnić, o tym później). Nie chce też znowu wałkować manuala, dlatego link do instrukcji warunkowych znajdziecie na dole, ale co jest ważne, konstrukcja musi zwrócić wartość BOOLEAN, ale to jest chyba oczywiste. W postgresie nie mamy znaku porównania tak jak w innych językach, a chodzi mi o podwójny znak równa się ==, tutaj jest tylko pojedynczy znak równa się. No i teraz, kiedy rozróżnić oba te znaki? Otóż bardzo prosto, porównanie jest tylko i wyłącznie w konstrukcjach warunkowych, użycie znaku równa się w postaci:

"_someVar" = "someVar2";

Jest niczym innym jak przypisaniem, i tak samo jak w każdym innym języku programowania jest l-value i r-value, ale o tym już kiedyś wspominałem, także nie będę tego przytaczał ponownie. Jest także inna konstrukcja która pozwoli nam przypisywać wartość zmiennej. Może ktoś z Was kojarzy język „Prolog”? Jak nie to nie ważne, ale w nim jest użyty taki przełącznik warunkowy „:-” a w postgresie mamy „:=” jako alias do „=” z tym że jest to tylko i wyłącznie przypisanie wartości do zmiennej. Także zachęcam Was do używania takiej oto konstrukcji przypisywania:

"_someVar" := "someVar2";

Jest ona czytelna, i oczywista, z niczym innym się kojarzyć nie może jak z przypisaniem.

Wracając do konstrukcji warunkowych to pozostało nam do opisania jeszcze CASE, jest to po prostu cudowna rzecz, coś wspaniałego, gdyż używanie IFów w SELECTcie jest po prostu mało czytelne i niewygodne. Dlatego dostaliśmy CASE, taki postgresowy switch. Do rzeczy, składnia CASE jest dwojaka:

CASE WHEN condition THEN result
     [WHEN ...]
     [ELSE result]
END

albo:

CASE expression
    WHEN value THEN result
    [WHEN ...]
    [ELSE result]
END

W zależności od potrzeb, używamy jednej z nich, ale mała podpowiedź kiedy którą wybrać, otóż gdy mamy warunek na danej kolumnie to lepiej wybrać wariant drugi, podając tą kolumnę jako expression, gdy mamy parę warunków na różnych kolumnach łatwiej jest wtedy operować nimi na pierwszym przykładzie, przykłady w manualau, a ja dwa słowa o wyniku z THEN, otóż podana fraza w THEN zostanie bezwzględnie dorzucona do wyniku zapytania, czyli dzięki temu w THEN możemy podać np nazwę kolumny jaką byśmy chcieli pobrać w zależności o warunku, który zostanie spełniony. nie sprawdzałem ale pewnie też z tego poziomu można by wywołać funkcję. Warto spróbować kiedyś.

To by było tyle na temat CASE i IF, oprócz tego mamy jeszcze takie funkcje jak NULLIF, COALESCE, GREATEST i LEAST. Krótko o tych funkcjach:

COALESCE: Konstrukcja COALESCE(value [, ...]). Zwraca pierwszy argument który nie jest NULLem.
NULLIF: Konstrukcja NULLIF(value1, value2). Zwraca NULL gdy value1 jest równe value2.
GREATEST: Konstrukcja GREATEST(value [, ...]). Zwraca największą wartość z listy argumentów.
LEAST: Konstrukcja jak powyżej, tylko działa na odwrót.

Pętle

Do zobaczenia w przyszłym wpisie pętelki moje kochane.

Wprowadzenie do PL/pgSQL

Krótki i w miarę logicznie opisanym słowem wstępu jest artykuł na wiki o PL/pgSQL, link poniżej. Lecz ja chciałbym to omówić po swojemu, tak by każdy z Was to zrozumiał i przekonał się nad wielkością tego języka, zaczynajmy.
Tak jak nam mówi manual składnia funkcji jest następująca:

CREATE FUNCTION "nazwaFunkcji"( argumenty [, ... ] ) RETURNS [typZwracanegoObiektu] AS $BODY$
  DECLARE -- blok nie obowiązkowy
    -- Możemy w tym bloku definiować zmienne, w "locie" zmiennych definiować nie możemy 
  BEGIN
    -- ciało funkcji
 
    RETURN [zwracanyObiekt] -- klauzula prawie nie obowiązkowa, o tym poniżej
  END;
$BODY$ LANGUAGE 'plpgsql';

Tak mniej więcej przedstawia się schemat konstrukcji funkcji w PL/pgSQL, Pominąłem kwestię bloków w bloku, w sensie że w bloku BEGIN … END możemy zdefiniować kolejny blok kodu. Nigdy mi to nie było jeszcze potrzebne, i wątpię by Wam było, to jest pewnego rodzaju przerost formy nad treścią. Jak widać stosuje tutaj podwójne dolary w sensie $BODY$, można się zapytać dlaczego? Otóż nie musicie stosować podwójnych dolarów zamiast nich możecie zrobić po prostu AS ‘ — i tutaj reszta kodu. Tylko nie wiem czy stać Was na nerwy stracone przy escepowaniu znaków. Otóż przy podwójnych dolarach możemy zachować taką konstrukcję:

SELECT * FROM users WHERE f_name='foobar';

Natomiast przy konstrucji z apostrofem:

SELECT * FROM users WHERE f_name=''foobar'';

Tam nie ma cudzysłowu przy foobar tylko podwójny apostrof. Także używajcie sobie czego chcecie, do woli. A i jeszcze jedno, to co sobie wstawicie pomiędzy podwójne dolarki nie ma znaczenia, ja wyniosłem z pracy nawyk wstawiania tam nazwy funkcji, co mi się osobiście trochę mało podoba, no ale nawyk pozostał. Przedstawiona przeze mnie powyżej konstrukcja nie jest oczywiście odzwierciedleniem tej z manuala, gdyż jest mało jasna, i rzadko się używa np CREATE OR REPLACE gdy co chwilę zmieniamy typy zmiennych przesyłanych w liście argumentów.

Argumenty funkcji PL/pgSQL

Lista argumentów może być podawana dwojako, a nawet trzyjako. Pierwszym z sposobów podawania argumentów do funkcji jest:

CREAT.... "nazwaFunkcji" ( INT, NUMERIC, TEXT, VARCHAR ) .... $BODY$
  DECLARE
    "_nazwaZmiennejInt" ALIAS FOR $1;
    "_nazwaZmiennejNumeric" ALIAS FOR $2;
    "_nazwaZmiennejText" ALIAS FOR $3;
    "_nazwaZmiennejVarchar" ALIAS FOR $4;
  BEGIN
   ....

drugi sposób:

CREAT.... "nazwaFunkcji" ( "_nazwaZmiennejInt" INT, "_nazwaZmiennejNumeric" NUMERIC,  "_nazwaZmiennejText" TEXT, "_nazwaZmiennejVarchar" VARCHAR ) .... $BODY$

trzeci sposób:

CREAT.... "nazwaFunkcji" ( "_nazwaZmiennejInt" INT, OUT "_nazwZwracanejZmiennej" INT, OUT "_nazwaZwracanejZmiennej2" INT ) .... $BODY$

Dzięki tej trzeciej metodzie możemy zwracać więcej niż jeden argument. Możemy też definiować typy zmiennych i też je zwracać o tym zraz.

Zwracane typy

Tak jak wyżej napisałem funkcje PostgreSQL mogą zwracać typy danych które też sami zdefiniujemy, metody mogą zwracać zarówno typ VOID, jeżeli nie potrzebujemy niczego zwrócić to po prostu ustawiamy RETURNS VOID i dzięki takiej konstrukcji klauzula RETURN w ciele kodu jest niewymagana, proste nie?
PostgreSQL to nie PHP, źle mu prześlesz typ danych zdefiniowany jako INT a prześlesz jako ’1′ i będzie to string, w PHP to przejdzie ale w postgre nie. Więc tutaj musimy się pilnować jeżeli chodzi o przesyłanie zmiennych. To samo tyczy się wszystkich typów oraz tych zwracanych, jeżeli w końcowej wersji uzyskamy inny typ niż ten który zdefiniowaliśmy to dostaniemy błędem po oczach próbując przypisać np NUMERIC do INT i w sumie funkcja się nie wykona, nic nie zwróci a weź to debuguj :>

Przykłady

A teraz prosty przykładzik:

CREATE TABLE "foo" ( "id" SERIAL, "bar" TEXT );
 
CREATE FUNCTION "fooBar"( "_bar" TEXT ) RETURNS VOID AS $$
  BEGIN
    INSERT INTO
      "foo"
    (
      "bar"
    )
    VALUES
    (
      "_bar"
    );
  END;
$$ LANGUAGE 'plpgsql';

I teraz przykład użycia:

SELECT "fooBar"( 'Terefere' );

Wykonanie takiego zapytania odpali nam naszą funkcję i wykonana kod w ciele metody.

Parę słów na zakończenie

To był pierwszy wpis z cyklu poświęconego językowi PL/pgSQL, temat jest szeroki jak rzeka i głęboki jak morze. Nie da się wszystkie na raz opisać, nie da się wszystkiego przedstawić i omówić szczegółowo. Następne wpisy będą dotyczyły instrukcji warunkowych oraz pętli. Wszystko możecie oczywiście znaleźć pod linkiem w stopce. Zapomniałbym wszystko co tutaj jest opisywane jest testowane pod najnowszą ver. oznaczoną numerkiem 8.4. Gdy wyjdzie nowsza i w repo będzie siedzieć to poinformuje o zmianie.

Co nam oferuje KDevelop

KDevelop i PHP

• Tworzenie projektów
• Obsługa SVN z poziomu programu
• Kolorowanie składni
• Integracja z manualem PHP
• Autosugestia metod w klasach
• Autosugestia nazw zmiennych ( :p )
• i wiele wiele wiele… more

Otóż po rozmowie z twórcą pluginu i zgłoszeniu paru błędów wiem czego na razie nie ma, nie działają podpowiedzi w statycznym wywoływaniu metod np:

SomeClassName::

Nie dostaniemy listeningu metod statycznych. Mi przynajmniej nie działa, on mówi że mu działa, eee nie wiem co jest grane ;]

KDevelop posiada kolorowanie składni również dla wielu wielu innych języków skryptowych. Wspaniałością jest to iż posiada kolorowanie składni dla skryptów SQL, tudzież PostgreSQL. Gdzie dla mnie to jest po prostu cudowna sprawa, ale był błąd w kolorowaniu składni procedur w języku pl/pgsql (będzie mini kurs wprowadzający w programowaniu pl/sql). By naprawić kolorowanie w tymże języku należy pobrać:
sql-postgresql.xml plik i wrzucić go do:

$ /usr/share/kde4/apps/katepart/syntax/

tam już takowy plik będzie, zróbmy sobie pierw jego kopie, a następnie wrzućmy nowy. Po tej całej operacji restart KDevelop i będzie nam piknie działać. Napisałem że ma błąd w kolorowaniu składni ale nie napisałem jaki, otóż sprawa ma się tak, przyjrzyjmy się funkcji:

CREATE FUNCTION "getMenuPath" ( "_idMenu" INT ) RETURNS LTREE AS $BODY$
	SELECT
	   "menuPath"
	FROM
	   "menu"
	WHERE
	   "idMenu" = $1;
$BODY$ LANGUAGE 'SQL' WITH (ISCACHABLE);

Jak widzimy po strukturze $BODY$ mamy ciało SQL, natomiast KDevelop interpretował to jako string, i tutaj był problem z kolorowaniem składni.

Błędy w KDevelop

Jest parę błędów w KDevelop które często powodują że nurtują mnie pytania czy dobrze zrobiłem że się na KDevelop przesiadłem, otóż mimo iż jest to oficjalne wydanie środowisko jest dosyć nie stabilne. Potrafi się często wyłożyć w najmniej oczekiwanych momentach, dlatego np odradzam korzystanie z SVN w KDevelop a wykorzystać do tego zewnętrzny program np: kdesvn, lub po prostu jechać z konsoli.
Czasami potrafi się też wysypać przy zamykaniu zakładek otwartych dokumentów. Innym ficzerem jest też taka opcja że gdy się najedzie na funkcję w php to pokazuje się tooltip ballon z informacją o funckji z linkiem w środku: Show uses, po kliknięciu na niego najprawdopodobniej powinny się pojawić jakieś przykłady jak to użyć, ale pojawia się nowe okno z paskiem postępu i cały KDevelop zdechł.

Praca z KDevelop

Wszystko co nam potrzebne do pracy z KDevelop to kawałek internetu, 3kilo root’a i z 2 głośniki. Polecam też zainstalowanie paczek z debug symbols.

$ sudo apt-get install kdevelop kdevelop-php [ kdevelop-php-docs -- integracja z manualem php.net] [ kdevplatform-dbg -- opcjonalne ]

I możemy zacząć naszą pracę z KDevelop, utworzyć sobie projekt, później do projektu pobrać dane po svn, lub też i nie jeżeli takiego projektu nigdzie nie przechowujemy na zewnątrz.

To by było na tyle, te informacje miały Was zachęcić do przejścia na platformę KDE oraz używania IDE KDevelop.

Konfiguracja /etc/hosts

Pierwej przed przystąpieniem do pracy i konfiguracji vhostów sprawdźmy sobie ustawienia naszego /etc/hosts, zakładamy że chcemy pracować tylko lokalnie i mieć vhosty dla swojej wygody pracując na lokalnej maszynie. Także edytujmy plik posiadając uprawnienia użytkownika root:

$ sudo su

następnie po wpisaniu hasła edytujemy plik:

$ nano /etc/hosts

I interesują nas pierwsze dwie linijki:

127.0.0.1       localhost.localdomain
127.0.1.1       nazwa-kompa

Tak powinień się nam przedstawiać nasz /etc/hosts, gdzie nazwa-kompa jest nazwą która wyświetli Wam się po wykonaniu polecenia:

$ echo $HOSTNAME

jeżeli tak mniej więcej wygląda Wasz plik hosts to ja proponuje takie rozwiązanie:

127.0.0.1       localhost.localdomain   nazwa-kompa
#127.0.1.1      nazwa-kompa

Jak widać 127.0.1.1 jest zaremowane więc nie jest brane pod uwagę. Czasami jest lepiej coś zaremować niż usuwać.

Na tym zakończymy na razie edycję pliku /etc/hosts

Konfiguracja vhosta

Przechodząc do edycji vhosta na samym początku chciałbym poinformować o pewnych zmianach wprowadzanych w ubuntu systematycznie, otóż mamy taki ciekawy program który się nazywa service i nie musimy latać do /etc/init.d/ by robić coś z aktualnie odpalonym deamonem. Czyli np taka komenda:

$ service apache2 restart

da nam to samo co:

$ /etc/init.d/apache2 restart

Używać do woli, co komu się podoba.

Gdzie są trzymane konfiguracje vhostów? Konfiguracje vhostów trzymane są w /etc/apache2/sites-available w postaci zwykłego pliku textowego bez żadnego rozszerzenia.
Budowę mają dość prostą, a co do budowy to przedstawię Wam przykład:

<VirtualHost *:80>
        ServerAdmin webmaster@localhost
 
        ServerName      bdt.local
        ServerAlias     www.bdt.local
 
        DocumentRoot "/home/cojack/Dokumenty/Projekty/BDT/web"
 
        <Directory "/home/cojack/Dokumenty/Projekty/BPDT/web">
                Options Indexes FollowSymLinks MultiViews
                AllowOverride All
                Order Allow,Deny
                Allow from All
        </Directory>
 
        ErrorLog "/home/cojack/Dokumenty/Projekty/BDT/tmp/logs/error.log"
 
        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn
 
        CustomLog "/home/cojack/Dokumenty/Projekty/BDT/tmp/logs/access.log" combined
 
        RewriteLog "/home/cojack/Dokumenty/Projekty/BDT/tmp/logs/rewrite.log"
        RewriteLogLevel 3
</VirtualHost>

Dyrektyw mi się opisywać nie chce, możecie o nich poczytać na stronie apache, ale jak widać wskazuje też miejsce logów (access, error, rewrite) dla danego vhosta, te katalogi muszą już istnieć przed przeładowaniem ustawień apache i dobrze by było gdyby były pod kontrolą usera i grupy www-data.

W „/home/cojack/Dokumenty/Projekty/BDT/web” posiadam plik index.php oraz , i od tego miejsca się wszystko zaczyna. Wystarczy teraz utworzyć plik np: bdt w katalogu /etc/apache/sites-available i wkleić do niego zawartość tego listingu powyżej. Oczywiście u Was on nie zadziała o ile nie macie poprawnych ścieżek tak jak powyżej. Także utwórzcie sobie własne ścieżki, nazwijcie jakoś projekt, i analogicznie do mojego vhosta utwórzcie swojego.

Po wykonaniu takiej operacji pozostały nam już tylko dwie rzeczy do wykonania. Pierwsza z nich to:

$ a2ensite bdt

u Was oczywiście analogicznie (względem powyższych wskazówek) będzie to coś innego niż bdt.

Konfiguracja pliku hosts raz jeszcze

Po wykonaniu wszystkich powyższych czynności by w adresie przeglądarki zadziałał nam nasz adres musimy jeszcze dodać wpis o tym:

127.0.0.1       bdt.local       www.bdt.local

Dodajemy ten wpis po naszej wstępnej konfiguracji zapisujemy i wpisujemy w pasku adresu przeglądarki adres: www.bdt.local i włala!

Możliwe problemy

* 403 Forbidden – szczerze? To nie pamiętam jak go rozwiązałem ;p
* Kiedy okaże się że mamy jakiś błąd w konfiguracji vhosta to nie pamiętam już czy apache skuma się po zmianie wpisu i akcji reload, ja zawsze dla pewności wykonywałem takie czynności:
a2dissite bdt
a2ensite bdt
service apache2 reload
* poleciłbym przed dodawaniem vhostów wyłączyć apache i zrobić tail -f /var/log/apache2/error.log i nasłuchiwać co go boli przy starcie jeżeli coś go boli.
* bliżej lub dalej nie określone problemy
* literówki w artykule.

Aha tą czynność mamy się rozumieć wykonujemy dla każdego z vhosta.

To by było na tyle. W następnym arcie będzie o konfiguracji vhost z ssl. Cza spać 1.45 na zegarku ;/

class A { 
  public function __construct(){ 
    $this->fuck(); 
  }  
}  
 
class B extends A { 
  public function __construct() { 
    parent::__construct(); 
  }  
 
  public function fuck() {
    echo "yo\n";
  } 
} 
 
$objB = new B();

A teraz zgadnijcie jaki będzie wynik, otóż zaskoczę Was, wynik to yo. A teraz wytłumaczenie dlaczego tak to działa:

„Obiekt jeszcze przed wywołaniem konstruktora klasy A już posiada wszystkie metody klasy B”

Innymi słowy metody są przypisane do obiektu a nie do klasy.

A żeby jeszcze było śmieszniej to kolejność wykonywania funkcji, popatrzcie sami:

class A { 
  public function __construct(){ 
    $this->fuck(); 
  }
 
  public function fuck() {
    echo "wow\n";
  }
}  
 
class B extends A { 
  public function __construct() { 
    parent::__construct(); 
  }  
 
  public function fuck() {
    echo "yo\n";
    parent::fuck();
  } 
} 
 
$objB = new B();

W kolejności wywoła się : yo a następnie wow. Dla mnie to powinna być pętla wow -> yo -> wow, a oczywiście jest inaczej.

Boże zlituj się nad developerami php i nie zważaj na grzechy ich.

CREATE [ OR REPLACE ] [ TEMP | TEMPORARY ] VIEW name [ ( column_name [, ...] ) ]
    AS query

Sama składnia może się wydawać prosta choć nie musi ;] składnia podana w nawiasach kwadratowych jest opcjonalna. Prze zemnie rzadko wykorzystywana, bo nie tworzę jakiś tymczasowych widoków, nie zapisuję widoku do innego schematu niż ten w którym się znajduję ani też nie używam OR REPLACE gdyż jak instaluje na nowo to drop db i amba.

Teraz może co do samej składni

OR REPLACE – co dziwnego o tym piszą w manualu, to się można dowiedzieć na stronie podanej poniżej. Ale przytoczę fragment.

CREATE OR REPLACE VIEW is similar, but if a view of the same name already exists, it is replaced. The new query must generate the same columns that were generated by the existing view query (that is, the same column names in the same order and with the same data types), but it may add additional columns to the end of the list. The calculations giving rise to the output columns may be completely different.

I teraz pytanie, po czorta w takim razie OR REPLACE jeżeli zmienimy sobie całkowicie widok a pozostawimy tą samą nazwę, trochę dziwna akcja, chociaż może nas to też z jednej strony zabezpieczać przed nałogowym wstawianiu OR REPLACE i nie daj Bóg strzelimy gdzieś dwa takie same nazwy widoków, hmmm w sumie może i dobrze.

Przykład jakiegoś widoku? Proszę bardzo, z naszego RBAC’a z zapytania sprawdzającego uprawnienia, zróbmy sobie teraz widok:

CREATE VIEW "checkRightView" AS
SELECT 
  "allow",
  "u2g"."idUser",
  "m"."moduleName",
  "a"."actionName"
FROM 
  "rbac_privilages" p 
LEFT JOIN 
  "rbac_module" m 
ON 
  ( p."idModule" = m."idModule" ) 
LEFT JOIN 
  "rbac_action" a 
ON 
  ( p."idAction" = a."idAction" ) 
LEFT JOIN 
  "rbac_user_to_group" u2g 
ON 
  ( p."idGroup" = u2g."idGroup" );

Dodaliśmy tylko nagłówek create view i ucięliśmy klauzule where, a teraz przykład jak takiego widoku użyć:

SELECT 
  "cRV"."allow"
FROM 
  "checkRightView" AS "cRV"  -- prawie jak honda ^^
WHERE 
  "cRV"."idUser" = 2 
AND 
  "cRV"."moduleName" = 'music' 
AND 
  "cRV"."actionName" = 'index';

Tadam, proste prawda? Tworzenie widoków można by porównać do polimorfizmu, lecz nim nie jest. Co nam to daje? Na pewno przejrzyste zapytania sql, co do debugowania to w sql zawsze był z tym problem, dlatego przed utworzeniem widoku pierw lepiej sprawdzić czy zapytanie śmiga.

Co do ograniczeń widoku, wiążą się z tym pewne niedogodności, gdyż jak widać by mieć dostęp do tabel łączonych w zapytaniu, trzeba pobrać ich elementy w samym zapytaniu (w widoku) by mieć do nich dostęp przy wywoływaniu widoku. Cóż jak to uważam za pewne ograniczenia, czy nim jest teoretycznie? Nie mam takiej wiedzy by to stwierdzić.

Mam nadzieję że ta krótka notka pomoże nie którym zgłębić swoją wiedzę.