Opis problemu:
Jak z poziomu kontrolera, ograniczyć wysyłaną kolekcję do widoku, poprzez parametr związany z D_NAME pochodzącego z tabeli niższego rzędu: TABELA_D?
Informacje wstępne:
TABELA A, zawiera kolumny: A_ID, B_ID, C_ID, gdzie B i C są kluczami obcymi z tabel B i C. : )
TABELA B, zawiera kolumny B_ID, D_ID, E_ID gdzie D i E są kluczami obcymi z tabel D i E.
TABELA D, zawiera kolumny D_ID, D_NAME.
Kontroler wysyła do widoku kolekcję, która na jej podstawie generuje sobie widoki.
Mogę ograniczyć wysyłaną kolekcję, poprzez ograniczenia wynikających z zapytań SQL’owych, np. @valuesA = A.find(:all, :conditions => [“B_id = ? AND C_ID > ?”, params[:B], params[:C]])
Pisywałem nieśmiało do wujka googl’a o odpowiedź, ale nic nie znalazłem. Nawet nie wiem za bardzo pod jakim hasłem szukać rozwiązania problemu.
Aaaaaa. Przetłumacz to na jakieś znaczące nazwy tabel. Możesz je wymyślić lub podać prawdziwe; i tak nikt nie wie nad jakim projektem pracujesz. W A B i C bardzo trudno się połapać. Nie jesteśmy maszynami.
Oczywiście to zadziała tylko wtedy gdy masz już zdefiniowane relacje w modelach dla A relacje do :b i :c, dla B relacje do :d i :e
Jeśli tych relacji nie masz możesz sam napisać cały join i przekazać go do find, all jako parametr :joins.
ZA API AR:
:joins - Either an SQL fragment for additional joins like “LEFT JOIN comments ON comments.post_id = id” (rarely needed), named associations in the same form used for the :include option, which will perform an INNER JOIN on the associated table(s), or an array containing a mixture of both strings and named associations. If the value is a string, then the records will be returned read-only since they will have attributes that do not correspond to the table’s columns. Pass :readonly => false to override.
:include - Names associations that should be loaded alongside. The symbols named refer to already defined associations. See eager loading under Associations.
Przenalizuję ją na dniach i dam znać jak mi poszło : )
p.s. tak, z PJTK-i. ^^ a czemu pytasz? To istotne? xD
p.s#2 A napisałem na ‘suchych’ danych, by było przejrzyściej. na drugi raz wezmę sugestię do serca.
Rozbawiło mnie to. Nazwy typu “A”, “A1”, etc. są tak przejrzyste, że aż przezroczyste, znaczy nie widać ich.
Kultura Rubiego tym rózni się od C, że nazwy metod, zmiennych, etc. są na tyle długie, że są zrozumiałe.
Kultura Rubiego tym rózni się od Javy, że nazwy metod, zmiennych, etc. są na tyle krótkie, że mieszczą się na ekranie.
[quote=apohllo]Kultura Rubiego tym rózni się od C, że nazwy metod, zmiennych, etc. są na tyle długie, że są zrozumiałe.
Kultura Rubiego tym rózni się od Javy, że nazwy metod, zmiennych, etc. są na tyle krótkie, że mieszczą się na ekranie.[/quote] #blipdnia
[quote=radarek][quote=apohllo]Kultura Rubiego tym rózni się od C, że nazwy metod, zmiennych, etc. są na tyle długie, że są zrozumiałe.
Kultura Rubiego tym rózni się od Javy, że nazwy metod, zmiennych, etc. są na tyle krótkie, że mieszczą się na ekranie.[/quote] #blipdnia :D[/quote]
Zmieściło się ?
[quote=radarek][quote=apohllo]Kultura Rubiego tym rózni się od C, że nazwy metod, zmiennych, etc. są na tyle długie, że są zrozumiałe.
Kultura Rubiego tym rózni się od Javy, że nazwy metod, zmiennych, etc. są na tyle krótkie, że mieszczą się na ekranie.[/quote] #blipdnia :D[/quote]
Muszę to jakość skompresować i dodać sobie jako sygnaturkę
Czyli różnica taka, że w warunkach musiałem dodać jeszcze wzięcie wszystkiego z tabeli A, po wybranym kluczu B. : )
Teraz widzę jak bardzo te nazwy są nie zrozumiałe xD
Wkleiłbym od razu fragment kodu z normalnymi nazwami, ale jako że jest to część pracy inżynierskiej to nie wiem czy mogę %)
p.s. czuję się zaszczycony że w zapoczątkowanym przeze mnie poście znalazł się #blipdnia :]
