Witam.

Czy normalne jest że ilość zwracanych danych przez obiekt sfOutputEscaperArrayDecorator (po wywołaniu polecenia doSelectJoinAll*()) jest nad wyraz duża?

W sumie wygląda na to że pobierając np. jeden artykuł z tabeli z artykułami (czyli jeden wiersz) z bazy przy pomocy np. doSelectJoinAutor() by np. prócz ID autora dostać też jego Nazwisko (z osobnej tabeli 'Autor') -> Propel zwraca:
1) obiekt 'Artykuł' (ok)
1a) obiekt 'Autor' powiązany z poprzednim obiektem 'Artykuł' (ok)
1b) wszystkie obiekty 'Artykuł' powiązane z pobranym punkt wcześniej obiektem 'Autor' (!)

Czy idzie jakoś wyeliminować bezużyteczny pkt. 1b) (oczywiście bezużyteczny gdy pobrane dane chcę tylko wyświetlić)
Bo jeżeli chcę pobrać jeden artykuł i jego autora, to propel zwróci mi tenże artykuł oraz dane autora, a poza tym 1000 obiektów typu 'Artykuł', które należą do tegoż autora....
Poprawnie to rozumiem? Jak tego uniknąć?

================================================================
Przykład:

Kod PHP:

[PHP] pobierz, plaintext 
<?php
public function executeLastNews()
    {
        $c = new Criteria();
        $c->add( ArticlePeer::IS_PUBLISHED, true );
        $c->add( CategoryPeer::IS_PUBLISHED, true );
        $c->addDescendingOrderByColumn( ArticlePeer::CREATED_AT );
        $c->setLimit( $this->items );
        $this->articles = ArticlePeer::doSelectJoinCategory($c);
    }// end executeLastNews();
?>
[PHP] pobierz, plaintext 

Wygenerowane zapytanie przez w/w funkcję doSelectJoinCategory():

[SQL] pobierz, plaintext 
SELECT article.ID, article.CATEGORY_ID, article.REGION_ID, article.PICTURE, article.TITLE, article.SHORT_DESC, article.DESC, article.IS_PUBLISHED, article.CREATED_AT, article.UPDATED_AT, category.ID, category.NAME, category.IS_PUBLISHED, category.CREATED_AT FROM `article` LEFT JOIN category ON (article.CATEGORY_ID=category.ID) WHERE article.IS_PUBLISHED=1 AND category.IS_PUBLISHED=1 ORDER BY article.CREATED_AT DESC LIMIT 3
[SQL] pobierz, plaintext 

Zwrócone przez bazę wyniki:

[SQL] pobierz, plaintext 
ID 	CATEGORY_ID 	REGION_ID 	PICTURE 	TITLE 	SHORT_DESC DESC IS_PUBLISHED 	CREATED_AT 	UPDATED_AT 	ID 	NAME 	IS_PUBLISHED 	CREATED_AT
5 	7 	20 	testowy_drugi.jpg 	Czy grozi nam powtórka zimy stulecia? 	Najbliższy tydzień upłynie pod znakiem gwałtownego... 	TO jest pełny opis.
Najbliższy tydzień upłynie pod... 	1 	2009-02-04 14:35:59 	2009-02-04 14:35:59 	7 	Teatr 	1 	2009-02-04 14:35:59
[SQL] pobierz, plaintext 

( wiem że ostatnie pole może mało czytelne, ale WSZYSTKO do tej pory jest naprawdę super, tak jak powinno być! )

Tyle że........
podczas var_dump( $articles ) dostaję taki oto obiekt:

[PHP] pobierz, plaintext 
<?php
object(sfOutputEscaperArrayDecorator)#65 (3) {
  ["count:private"]=>
  NULL
  ["value:protected"]=>
  array(1) {
    [0]=>
    object(Article)#90 (18) {
      ["id:protected"]=>
      int(5)
      ["category_id:protected"]=>
      int(7)
      ["region_id:protected"]=>
      int(20)
      ["picture:protected"]=>
      string(17) "testowy_drugi.jpg"
      ["title:protected"]=>
      string(38) "Czy grozi nam powtórka zimy stulecia?"
      ["short_desc:protected"]=>
      string(201) "Najbliższy tydzień upłynie pod znakiem gwałtownego ochłodzenia.
Temperatury spadną nawet poniżej -25 stopni. Czy grozi nam powtórka
z zimy stulecia? Wtedy też nic nie zapowiadało fali zimna.
"
      ["desc:protected"]=>
      string(1227) "To jest pełny opis.
Najbliższy tydzień upłynie pod znakiem gwałtownego ochłodzenia.
Temperatury spadną nawet poniżej -25 stopni. Czy grozi nam powtórka
z zimy stulecia? Wtedy też nic nie zapowiadało fali zimna. Itd."
      ["is_published:protected"]=>
      bool(true)
      ["created_at:protected"]=>
      string(19) "2009-02-04 14:35:59"
      ["updated_at:protected"]=>
      string(19) "2009-02-04 14:35:59"
      ["aCategory:protected"]=>
      object(Category)#91 (14) {
        ["id:protected"]=>
        int(7)
        ["name:protected"]=>
        string(5) "Teatr"
        ["is_published:protected"]=>
        bool(true)
        ["created_at:protected"]=>
        string(19) "2009-02-04 14:35:59"
        ["collThemaCategorys:protected"]=>
        NULL
        ["lastThemaCategoryCriteria:private"]=>
        NULL
        ["collArticles:protected"]=>
        array(1) {
          [0]=>
          object(Article)#90 (18) {
            ["id:protected"]=>
            int(5)
            ["category_id:protected"]=>
            int(7)
            ["region_id:protected"]=>
            int(20)
            ["picture:protected"]=>
            string(17) "testowy_drugi.jpg"
            ["title:protected"]=>
            string(38) "Czy grozi nam powtórka zimy stulecia?"
            ["short_desc:protected"]=>
            string(201) "Najbliższy tydzień upłynie pod znakiem gwałtownego ochłodzenia.
Temperatury spadną nawet poniżej -25 stopni. Czy grozi nam powtórka
z zimy stulecia? Wtedy też nic nie zapowiadało fali zimna.
"
            ["desc:protected"]=>
            string(1227) "To jest pełny opis.
Najbliższy tydzień upłynie pod znakiem gwałtownego ochłodzenia.
Temperatury spadną nawet poniżej -25 stopni. Czy grozi nam powtórka
z zimy stulecia? Wtedy też nic nie zapowiadało fali zimna. Itd."
            ["is_published:protected"]=>
            bool(true)
            ["created_at:protected"]=>
            string(19) "2009-02-04 14:35:59"
            ["updated_at:protected"]=>
            string(19) "2009-02-04 14:35:59"
            ["aCategory:protected"]=>
            object(Category)#91 (14) {
              ["id:protected"]=>
              int(7)
              ["name:protected"]=>
              string(5) "Teatr"
              ["is_published:protected"]=>
              bool(true)
              ["created_at:protected"]=>
              string(19) "2009-02-04 14:35:59"
              ["collThemaCategorys:protected"]=>
              NULL
              ["lastThemaCategoryCriteria:private"]=>
              NULL
              ["collArticles:protected"]=>
              array(1) {
                [0]=>
                *RECURSION*
              }
              ["lastArticleCriteria:private"]=>
              NULL
              ["alreadyInSave:protected"]=>
              bool(false)
              ["alreadyInValidation:protected"]=>
              bool(false)
              ["validationFailures:protected"]=>
              array(0) {
              }
              ["_new:private"]=>
              bool(false)
              ["_deleted:private"]=>
              bool(false)
              ["modifiedColumns:protected"]=>
              array(0) {
              }
            }
            ["aRegion:protected"]=>
            NULL
            ["alreadyInSave:protected"]=>
            bool(false)
            ["alreadyInValidation:protected"]=>
            bool(false)
            ["validationFailures:protected"]=>
            array(0) {
            }
            ["_new:private"]=>
            bool(false)
            ["_deleted:private"]=>
            bool(false)
            ["modifiedColumns:protected"]=>
            array(0) {
            }
          }
        }
        ["lastArticleCriteria:private"]=>
        NULL
        ["alreadyInSave:protected"]=>
        bool(false)
        ["alreadyInValidation:protected"]=>
        bool(false)
        ["validationFailures:protected"]=>
        array(0) {
        }
        ["_new:private"]=>
        bool(false)
        ["_deleted:private"]=>
        bool(false)
        ["modifiedColumns:protected"]=>
        array(0) {
        }
      }
      ["aRegion:protected"]=>
      NULL
      ["alreadyInSave:protected"]=>
      bool(false)
      ["alreadyInValidation:protected"]=>
      bool(false)
      ["validationFailures:protected"]=>
      array(0) {
      }
      ["_new:private"]=>
      bool(false)
      ["_deleted:private"]=>
      bool(false)
      ["modifiedColumns:protected"]=>
      array(0) {
      }
    }
  }
  ["escapingMethod:protected"]=>
  string(16) "esc_specialchars"
}
?>
[PHP] pobierz, plaintext 

I to tylko dla jednego rekordu... Jakbym chciał pobrać ich 100, to aż strach pomyśleć jak obciążyłoby to pamięć :/.
Obłęd.

Najlepszym rozwiazaniem jest vidok. Dodaje sporego kopa jesli chodzi o wydajnosc wyciagania danaych i wielki spadek zuzycia pamieci.

Nie no, jeszcze widoki tworzyć? Tylko po to by móc korzystać z Propela i jednocześnie używać mało zasobów?

Szczerze powiedziawszy - co daje korzystanie z Propela?? Bo jak na razie doczytałem się jednego -> abstrakcyjności jeżeli chodzi o bazy, w tym głownie przytaczany przykład w stylu "jak będziesz chciał zmienić nazwę tabeli/kolumny"...

Ale tak szczerze powiedziawszy -> kto zmienia nazwy tabel / kolumn po zakończeniu tworzenia projektu?!?! może 0,00000000000001% programistów... Po drugie: kto zmienia nawet bazę na inną (np. z MySQL na Postgre) No, tu może być więcej osób, może z 0,1%.....

Nie widzę jak na razie sensu korzystania z metod Propela. Co prawda pisanie 'zapytań' jest prostsze, ale z doświadczenia wiadomo że te samo zapytanie generujące identyczne wyniki za pomocą Propela a czystego SQLa trwa KILKA RAZY dłużej... Szczęście w nieszczęściu że Propel rusza taką samą liczbę wierszy.

Przykład:
Wynik: 3 wiersze z artykułami połączone z nazwami regionów oraz nazwami kategorii do których należą.

Wygenerowane zapytanie przez PROPEL:

[SQL] pobierz, plaintext 
SELECT article.ID, article.CATEGORY_ID, article.REGION_ID, article.PICTURE, article.TITLE, article.SHORT_DESC, article.DESC, article.IS_PUBLISHED, article.CREATED_AT, article.UPDATED_AT, category.ID, category.NAME, category.IS_PUBLISHED, category.CREATED_AT, region.ID, region.NAME FROM `article` CROSS JOIN `thema` LEFT JOIN category ON (article.CATEGORY_ID=category.ID) LEFT JOIN region ON (article.REGION_ID=region.ID) WHERE article.IS_PUBLISHED=1 AND category.IS_PUBLISHED=1 AND thema.IS_PUBLISHED=1 ORDER BY article.CREATED_AT DESC LIMIT 3
[SQL] pobierz, plaintext 

Zapytanie moje:

[SQL] pobierz, plaintext 
SELECT article.*, category.name AS category_name, region.name AS region_name FROM article, category, thema, thema_category, region WHERE article.is_published=1 AND category.id=article.category_id AND thema_category.category_id=article.category_id AND thema.id=thema_category.thema_id AND category.is_published=1 AND thema.is_published=1 AND article.region_id=region.id ORDER BY article.CREATED_AT DESC LIMIT 3
[SQL] pobierz, plaintext 

Wynik identyczny. W pierwszym przypadku Propel rusza o dziwo 2 tabele, w drugim ruszam aż 5, ale ilość ruszonych wierszy w obydwu przypadkach jest taka sama (odpowiednio: 2*3 i 2*1*1*3*1). Ale najciekawsza jest różnica w czasie - zapytanie Propela trwa 0,0027s, moje 0,0006s. [poprawka: czas jest także taki sam ;> - nie dałem w swoim zapytaniu sortowania... teraz już poprawione]

Nie wspomnę już o 2MB różnicy w wykorzystaniu zasobów pamięci serwera... 2MB! - dla 3 zwróconych rekordów!

Wiem że Ameryki nie odkryłem, ale jednak - różnice są ogromne. Dlaczego ludzie korzystają z Propela to wciąż nie wiem. Akurat plus w przenośności systemu moim zdaniem nie rekompensuje różnic w wydajności (użytkownicy odwiedzają stronę codziennie, a system przenosi się raz na parę lat i to może max z 2x)...

PS.
Nie wiem jak z Propelem, ale od kumpla programisty słyszałem że Doctrine potrafi wypluć takie wyniki z bazy, że var_dump() na obiekcie z wynikami powoduje zawieszenie się przeglądarki... ehhh. Po Propelu też się tego bym spodziewał patrząc na przykład z pierwszego posta.

Interesuje mnie na razie jedno: Istnieje możliwość zmuszenia Propela do wyplucia obiektu wynikowego zawierającego TYLKO obiekty stworzone ze zwróconych przez bazę wierszy? (z pominięciem całych odzwierciedlonych tam struktur nikomu nie potrzebnych w normalnym wyświetlaniu wyników)

Ok, widze ze wiele teorii przed Toba. Co to Propel - szukaj w google ORM przeycztaj kilka art przemysl sprawe zanim zaczniesz pisac glupsta na forum. Nie ma sensu pisac, jest tyle materialow propel to nic nowego. W wiekszosci jezykow istnieje ORM. Co do obiektow ktore wypluwa propel, fakt zgadzam sie ze to troche zajmuje w pamieci. Ale nie sadze ze w Twoim projekcie zawsze chcesz wykorzystywac wszystkie dane z tabeli. Kolejna rzecza to teoria baz danych, nie wiem czy wiesz ale zwracanie wynikow z calej tabeli ( wszystkich pol ) jest wolniejsze od "kilku" pol - nie wierzysz sprawdz, ale to mam nadzieje ze dla Ciebie jest logiczne. Idac dalej jesli robisz zlaczenia do wielu tabel to oczywiste ze kazdy orm bedzie budowal obiekty ze wszystkich danych - a co za tym idzie, zużycie pamięci bedzie wzrastać. Do daje vidok to chyba nie musze tlumaczyc - propel ma mozliwosc zbudowania modelu do odczytu z vidoku. To sa rzeczy tak logiczne i wynikajace same z siebie ze chyba nie trzeba tlumaczyc.

No tak, rację masz że ORM stanowi dla mnie (jeszcze?) tajemnicę, mimo to jeżeli var_dump() na wynikach średnio skomplikowanego zapytania (nie mówię tu o systemie bloga, prostej stronki z cms'em, tylko bardziej rozbudowanego systemu / portalu) powoduje zawiechę przeglądarki (lub błędy serwera typu 'Memory Exhausted') to chyba coś z tym nie tak...

PS.
Co do wypisywania głupstw - gdzie Ty głupstwa widzisz? . Przecież przytoczyłem tylko znane fakty i zadałem pytanie odnośnie tego czy można wymusić na Propelu zwrot wyników bez tej całej otoczki, bo do tego co chcę zrobić nie jest mi ona potrzebna. Wiem że Artykuł poszerzony o pole z wartością ID autora / kategorii / regionu to już nie obiekt Artukuł, ale może jakoś ominąć?

Pobierając tylko 3 artykuły (bo tyle chcę wyświetlić) z dołączonymi _wartościami_ pól xxx_id będącymi kluczami obcymi do innych tabel - Propel wypluwa takiego giganta, że nawet jakbym chciał przytoczyć go tutaj na forum, to nie da rady bo kilkunastokrotnie przekracza to możliwą długość posta. Dla 10ciu pobranych artykułów na bank przeglądarka przestała by odpowiadać (mówię ciągle o var_dumpie() na tymże obiekcie)... Czy to ja robię coś nie tak, czy też wszystko jest "w porządku" (czyt. nikt na to nie zwraca uwagi, nawet nie wie co to var_dump())?

pozdro.

ja się zastanawiam czy to z czym Ty masz problem było rozważane przez autorów Propela. przecież nad tym pracują ludzie raczej myślący. dlaczego oni takich problemów nie mają? dlaczego mimo wszystko wypuścili taką aplikację i dlaczego była ona dołączona do dosyć sporego frameworka Symfony? czyżby to wszystko było nieporozumieniem?
tak się tylko zastanawiam:)

Budując system do obsługi bloga, do obsługi galerii internetowej, do obsługi katalogu on-line - tak, można sobie pozwolić na zajęcie pamięci rzędu kilkunastu / kilkudziesięciu MB dla jednego żądania.... Ale np. robiąc portal, zaawansowany sklep itp - każdy MB zasobów jest na wagę złota. Z resztą błędy typu 'Memory Exhausted' są wg Ciebie przewidziane przez twórców? Pewnie nie, nawet przy ogromnych projektach...

Dlatego pewnie robię gdzieś błąd, ale nie wiem gdzie. Jeżeli normalne jest że pobranie tylko 3 wierszy z bazy (powiązanych przeróżnymi relacjami kilku tabel) zajmuje horrendalną ilość pamięci i tak ma być - to cieszę się że nie robię nigdzie błędu.

Może źle to wszystko zabrzmiało co do tej pory napisałem -> nie chcę się kłócić, polemizować itp. bo się na tym nie znam. Wiem tylko tyle że wyciągając z bazy te durne trzy wiersze zjada mi 2MB pamięci, a var_dump() jest olbrzymi. Stąd moje rozważania, ubolewania itp.

Nigdy nie mieliście z tym problemów robiąc duże projekty?
Mi to jakoś spokoju nie daje :/.

może coś z var_dump jest nie tak? też jak sprawdzam dla 12 wierszy z bazy (trochę joinów) to apache dostaje zadyszki i nie odpowiada. ale może to nie o to chodzi?

myślę, że twórcy Symfony nie stworzyli tego frameworka do budowy bloga czy innych takich skromnych aplikacji:)

spróbuj Doctrine i najnowszego Symfony 1.2.4 - zobacz czy tam var_dump też zawiesza apache.

Z tego co wiem to Doctrine jest tak samo zasobożerny. Pobierane są chyba wszystkie powiązane ze sobą rekordy, nawet jak ich nie chcesz (i to nawet po kilka razy te same, co widać po var_dumpie). Tak gwoli zasady "a może programista będzie chciał ich użyć".

Kumpel który jest programistą nie-amatorem mówił że przy projektach robionych przez firmę gdzie pracował często zdarzało się że przy chęci wyciągnięcia 5ciu wierszy Doctrine pobierało dodatkowych kilkaset co powodowało błedy "Fatal error: Memory Exhausted..."... Patrząc na var_dumpy() wcale się nie dziwię.
No i dlatego jakoś mam obawy w korzystaniu z Propela/Doctrine w Symfony przez doSelect, doSelectJoinAll itp. Jak aplikacja mi się rozrośnie i nagle zaczną się sypać błędy z pamięcią to nie pozostani nic innego jak przebudowa wszystkiego :/.

@Ravv pomijajac juz sens propela bo to juz mam nadzieje ze wyjasnione. W SQLu ktory podales ktory wyrzuca propel masz tam jakiegos CROS JOIN "FROM `article` CROSS JOIN `thema`" podaj jakie kryteria ustawiasz.

Odnosnie tej pamieci napisze to kolejny raz - zwracasz wiecej wynikow, pol to tym wiecej pamieci PHP potrzebuje na obsluzenie tego - to chyba oczywiste. Jesli chesz optymalizowac dbac o pamiec to widoki sa 1 krokiem do tego.

Baza:

[SQL] pobierz, plaintext 
propel:
  [b]thema[/b]:
    id:				~
    name:			{ type: varchar(100), required: true }
    is_published:	{ type: BOOLEAN, required: true, DEFAULT: 1 }
    created_at:		~
 
  [b]category[/b]:
    id:				~		
    name:			{ type: varchar(100), required: true }
    is_published:	{ type: BOOLEAN, required: true, DEFAULT: 1 }
    created_at:		~
 
  [b]thema_category[/b]:
    thema_id:		{ type: integer, foreignTable: thema, foreignReference: id, required: true, primaryKey: true, onDelete: cascade }
    category_id:	{ type: integer, foreignTable: category, foreignReference: id, required: true, primaryKey: true, onDelete: cascade }
 
  [b]article[/b]:
    id:				~
    category_id:	{ type: integer, foreignTable: category, foreignReference: id, required: true }
    region_id:		{ type: integer, foreignTable: region, foreignReference: id }
    picture:		{ type: varchar(255) }
    title:			{ type: varchar(255), required: true }
    short_desc:		{ type: longvarchar }
    DESC:			{ type: longvarchar, required: true }
    is_published:	{ type: BOOLEAN, required: true, DEFAULT: 1 }
    created_at:		~
    updated_at:		~
[SQL] pobierz, plaintext 

Cel: pobranie trzech najnowszych artykułów. Artykuły muszą mieć status opublikowanych, kategorie do których należą również, tematy do których należą kategorie - też muszą mieć status opublikowane.

Kryteria:

[PHP] pobierz, plaintext 
<?php
$c = new Criteria();
$c->add( ArticlePeer::IS_PUBLISHED, true );
$c->add( CategoryPeer::IS_PUBLISHED, true );
$c->add( ThemaPeer::IS_PUBLISHED, true );
$c->addDescendingOrderByColumn( ArticlePeer::CREATED_AT );
$c->setLimit( 3 );
return ArticlePeer::doSelectJoinAll($c);
?>
[PHP] pobierz, plaintext 

Generowane zapytanie:

[SQL] pobierz, plaintext 
SELECT article.ID, article.CATEGORY_ID, article.REGION_ID, article.PICTURE, article.TITLE, article.SHORT_DESC, article.DESC, article.IS_PUBLISHED, article.CREATED_AT, article.UPDATED_AT, category.ID, category.NAME, category.IS_PUBLISHED, category.CREATED_AT, region.ID, region.NAME FROM `article` CROSS JOIN `thema` LEFT JOIN category ON (article.CATEGORY_ID=category.ID) LEFT JOIN region ON (article.REGION_ID=region.ID) WHERE article.IS_PUBLISHED=1 AND category.IS_PUBLISHED=1 AND thema.IS_PUBLISHED=1 ORDER BY article.CREATED_AT DESC LIMIT 3
[SQL] pobierz, plaintext 

var_dump'a nie wrzucę bo za duży, ale z tego co na szybkiego widzę stworzono po 13 obiektów tego samego artykułu (czyli 39 obiektów Article) itd.

Wiem że gdzieś robię błąd (oby!), dlatego byłbym rad za wskazanie.

No to teraz zobacz - ArticlePeer::doSelectJoinAll($c); pobiera Ci obiekty Article wraz z powiazanymi, nigdzie nie wyspepuje w kluczu thema. Zeby to wszystko polaczyc musisz dodac $c->addJoin( pole, pole );

Zacząłem kombinować z tymi kryteriami sukcesywnie zmniejszając liczbę powtórzeń obiektów. Niestety przy doSelectJoinAll() najmniejszy wynik to 6 (docelowo: 3). Próbowałem przez doSelect() i 3 addJoin'y -> prawie zadowalający wynik - 3 artykuły, ale bez powiązanych obiektów.

Tak w ogóle to w dokumentacji jest błąd, konkretnie > TUTAJ <, ponieważ pokazany przykład nie jest tożsamy z podanym tam zapytaniem, ponieważ zamiast SELECT * ..., doSelect() pobiera tylko kolumny z jednej tabeli :/. Szkoda... Coś czuję że znów czeka mnie nieprzespana noc by dojść do tego jak powinny wyglądać te kryteria, by dostać 3 obiekty artykułów + obiekty powiązane z każdym z nich.

Zły Propel, zły! Jak się walą w dokumentacji, ehh...

Jest tak jak powinno byc. W jednym zapytaniu chesz otrzymac obiekty zalezne ale pomiedzy nimi jest jeszcze tabela. Najrozsadniej jest uzyc widok i wtedy zwracasz co chcesz.

utworzyć widok w bazie to jest jedno rozwiązanie, innym może być samemu utworzenie albo poprawienie metod doselectjoinall.

@AxZx Tylko poprawienie metod nie zmieni Ci zbyt wiele w ilosci zajetej pamieci, chyba ze bedziesz zwracal odpowiednie pola, ale to zawsze cos.

a po co tworzyć widoki? po co w ogóle robić te dodatkowe metody? tzn po co zmuszać Propela do generowania dodatkowych metod? można w schema.yml nie podawać kluczy obcych - wtedy nie będzie dodatkowych obiektów dołączał, które czasem są nie przydatne.

a jak później jest z hydrate takiego widoku? gdy chcemy mieć dane z 5 tabel? nie będzie problemów?

Widok w propelu to tak naprawde model do oczytu. A jakie dane sa zwracane to tylko zalezy od struktury vidoku. Hydrate w Propelu jest defaultowy. Postaram sie art zrobic i wrzuce na bloga to pozniej podesle link z przykladami. Czesto takie zabiegi stosujemy w pracy w celu przyspieszenia Propela i zmniejszenia pamieci.

aaa, rozumiem. czyli po prostu w schema.yml tworzysz widok a nie tabele?
tylko to jest chyba strasznie sztywne rozwiązanie.
no i jeszcze nie wiem za bardzo jak to ugryźć.
załóżmy, że mam model profil. tam nadpisałem metody lub stworzyłem nowe metody np. getNazwa, setPseudonim itd.
tworząc widok, który miałby pobierać dane profilu połączone jeszcze z 5 innymi metodami z których metod będę mógł skorzystać? czy tych z modelu profil czy tylko tych z modelu tego widoku?

EDIT:

już wiem o co chodzi
http://zawadzinski.com/2008/01/15/how-to-u...ews-in-symfony/

trzeba będzie spróbować to wdrożyć:) a nie czekać, aż serwer sam zdechnie. aczkolwiek nie wiem czy jest sens, bo może się okazać, że taniej wyjdzie przenieść się na dedyka i dokładać RAM.

Uwierz mi ze nawet jesli przenieszesz to na dedyka ( nawet bardzo dobrego - RAM, CPU ) i dalej bedziesz mial tyle zaleznych obiektow to i on nie da rady, wiem to z doswiadczenia. Takie rzeczy od razu robic podczas fazy 1 implementacji. Rozumiem ze sie projekt moze zmieniac ale trzeba o tych rzeczach myslec - wiele opinii jest na temat Symfony ze to pamieciozerne, ze wolno chodzi - a prawda jest taka, ze jak sie nie mysli o tych rzeczach to taka teorie mozna przyjac, ktora jest dla mnie bardziej brakiem doswiadczenia niz bledna koncepcja developerow symfony. Zasada jest prosta - zwracaj to co Ci jest potrzebne.

Symfony - przyśpieszanie Propela z wykorzystaniem widoków (view) baz danych

a można zrobić tak jak pisałem wcześniej?
że w schema.yml nie podajesz kluczy obcych (powiązanych tabel) i wtedy propel nie będzie tworzył tych ogromnie długich plików modeli. a złączenia można robić samemu, samemu utworzyć metody, które łączą i zwracają tylko to co trzeba.

Tylko jak bedziesz pobieral juz w template zalezne dane to i tak zwroci Ci caly rekord + dodatkowe zapytanie a jak uzyjesz do addJoin to na to samo wyjdzie.

no nie zupełnie. bo wtedy w addjoin będzie dołączana tylko jedna tabela. tak mi się wydaje;) ale wydaje mi się, że już nic z tego nie rozumiem. symfony oferuje dużo możliwości. po co w takim razie z niego korzystać jak i tak trzeba samemu kombinować.
czy to znaczy, że symfony jest do robienia 'stronek' dla nie więcej niż powiedzmy 1000 odwiedzin dziennie?

A wyobrazasz sobie kryteria do 3 tabel z grupowaniem i innymi kombinacjami? A tak to przygotowujesz widok w SQL dodajesz do schema i budujesz i masz gotowe dane, tylko takie jakie maja byc wykorzystane, po co wyciagac niepotrzebne zalezne dane.