FindAll - oddzielna tabela

Możesz w akcji użyć loadModel

sposob z ClassRegistry::init...nie jest za bardzo optymalny moim zdaniem. Wywylujac ta funcje nie dosc ze dolaczasz dodatkowe 73 linijki kodu (tyle zajmuje init http://api.cakephp.org/view_source/clas … y/#line-98) to jeszcze w dodatku zasmiecasz pamiec niepotrzebnym obiektem.
Moim zdaniem najlepszym rozwiazaniem (jezeli nie chcesz dodawac modelu w zmiennej $uses) jest napisanie funkcji prywatnej (z przedrostkiem '_', aby nie mozna bylo jej wywolac z poziomu przegladarki) w modelu aktualnym np w pliku models/NazwaModelu.php stworzyc funkcje taka :

class NazwaModelu extends AppModel {
   
   ....
   ....
   ....
   function _getSlownik() {
     $data = $this->query('.....zapytanie do tabeli 'slowniki'');
     return $data;
  }
}

a w danym miejscu kontrollera wywolujesz ja w znany wszystkim sposob

//controller
$data = $this->NazwaModelu->_getSlowniki();

mam nadzieje ze sposob bedzie dla Twoich potrzeb optymalny

alez ja od samego poczatku uwazam iz jezeli robi sie wszystko we framewokru jakim jest cake , trzeba korzystac najwiecej jak to mozliwe z jego dobrodziejstw, trzymac sie zasady MVC, dobrze zaplanowac strukture, baze, kontrolery, widoki, modele, elementy..itd..itd.
Oczywiscie uzywajac takich metod (jak np. $this->query() ..z czego trzeba korzystac jak najmniej) mozna byloby w pewnym momencie dojsc do wniosku, paradoksalnie, iz caly serwis upchnac do jednego pliku, jakim jest np. bootstrap.php co nie jest cakefriendly
Osobiscie nie preferuje takich metod, ale jezeli na pewnym etapie realizacji serwisow, szczegolnie jezeli robi sie to po kims, lub jezeli serwis jest dosc duzy, a nie ma czasu na przebudowe, niestety trzeba uciec wlasnie do takich rozwiazan jak np. $this->query...
no..ale to debata na dlugie rozmowy na temat MVC oraz cakefriendly.
pozdrawiam serdecznie

To jest jaknabardziej optymalny sposób. Tworzenie kolejnych obiektow to zarowno wada jak i zaleta oop, pozatym ile taki obiekt może zająć miejsca w pamieci 1 - 2kb ?. Coś kosztem czegoś.

No właśnie.... to że  pomiędzy tabelami występują relacje, nie znaczy że musisz hardcodować wszelkie możliwe asocjacje w modelach. 90% asocacji powinno być zbindowanych w locie, zależnie od potrzeb, wtedy wszytsko jest ok.

Od wersji 1.2 nie ma asocjacji której byś nie utworzył, no może jest kilka specyficznych wyjątków, ale i w takich przypadkach da sie obejść bez custom query.

@duke ... zacytowany kawałek mojej wypowiedzi był kierowany do zdaje się usera "maciek".  Poztaym pislem odwzorowaniu relacji w asocacjach modeli.

Jezeli tej tabeli slownikowej chcesz uzywac tylko  do pracy z jednym modelem np User ...

Pozatym, $this->query powinno byc uzywane tylko w szczegolnych przypadkach... (pisales mi w jednym poscie ze unikalbys stosowania pola enum ze wzgledu na niezgodnosci w skladni sqla pomiedzy bazami ... a cale zapytania to juz mozna ? ) .. i do debugowania

<?php 
class User extends AppModel { }
// w tym samym pliku 

class Slownik extends AppModel  { // yeap konwencje kejka zezwalaja na umieszczanie kilku klas (np modeli) w tym samym pliku ;)
}

w przecywinym wypadku musisz uzyc kompozycji ( czyli poprostu zaladowac rejestrem zewnetrzny model).

Ja mam w AppModel teaka metode ....

    function getModelObject($modelName) {
        if(!$model = ClassRegistry::getObject($modelName)): // unikamy ladowania tego samogo modelu wielokrotnie
            $model = ClassRegistry::init($modelName,"Model"); // jednak model nie byl zaladowany wczesniej, no to zaladowac gada
            ClassRegistry::addObject($modelName,$model);    // wpychamy model do rejestru
        endif;                
        return $model;
    }


// i sposb uzycia :

$Slownik = $this->getModelObject("Slownik');

Ostatnio edytowany przez robal77 (2009-03-23 17:05:09)

Kto powiedział że pole enum nie może być indexem, wręcz przeciwnie. Każde pole, które jest kluczem obcym powinno być również indexem (ale w momęcie, w którym wszytskie pola są indexami trzeba się podrpać po głowie i zastanowić) - bd wtedy minimalnie szybciej sortuje sobie wyniki.

Wg mnie jeżeli coś istenieje to powinno się to stosować (z rozwagą oczywiście).

A kto powiedział, że nie stosuje bindowania w locie?
Miałem sporo przypadków, kiedy klienci wymagali stworzenia raportu, dla którego poziom skomplikowania powodował że jego skuteczne przeniesienie na ORM'a było niemożliwe.
Do prostych rzeczy - nadaje się idealnie, przy bardziej zaawansowanych - wysiada. Można tworzyć widoki, ale przecież nie o to w tym wszystkim chodzi...

Poza tym ilość zapytań jakie generuje Cake przy nawet niewielkim rekursywnym zagłębieniu modeli jest zatrważająca.

Co do enum - jest ładne, ale wolne. Spytajcie się dowolnego bazodanowca co będzie szybciej działało, a każdy wam powie że atrybuty typu całkowitego najlepiej nadają się do tworzenia kluczy ( i ich indeksowania) .
Przy min. 100tys. unikalnych wejść na stronę w ciągu dnia, nawet takie wydawało by się niewielkie rzeczy naprawdę mają znacznie.