Asocjacje

Zielona szkoła
1

Witam

Jestem w trakcie pisania malej aplikacji. Posiadam 2 modele, User i Project. User moze miec wiele projektow, projekt ma jednego wlasciciela (szefa), wiec samo nasuwa się has_many i belongs_to? Potrzebuje Jednak by moc zmienic szefa projektu jesli to bedzie potrzebne oraz dodawac uzytkownikow ktorzy beda pracowac przy projekcie? has_many through ? Z jakiego typu asocjacji najlepiej skorzystać by móc typować szefa i dodawać uzytkowników do projektu? Prosze Was o jakie kolwiek sugestie poniewaz nie mam obycia w railsach- raczkuje.

Pozdrawiam, Michał

2

jak dla mnie to powinna wystąpić relacja has and belongs to many. projekt ma owner_id czyli identyfikator “szefa”, a uczestnicy są wyświetlani przez has and belongs to many

3

Rozumiem, a jesli ilosc szefow tez bedzie mogla byc wieksza niz 1 ? Bo to tez wchodzi w gre, jak wowczas wywinac sie z tego?

Pozdrawiam, Michal

4

Proponuje użyć has_many :through,
model łączący możesz nazwać np. Participant i
w tym modelu ustawiać flagę admin/regular user (alternatywnie
możesz skorzystać z jakiegoś gotowego pluginu do autoryzacji).

5

Moim zdaniem najlepszym wyjściem będzie asocjacja habtm z wykorzystaniem has_many through. Tabela pośrednicząca może zawierać dodatkowe pole które będzie oznaczało czy to szef czy zwykły user.

EDIT: @fastred, byłeś szybszy :slight_smile:

6

Dzieki za pomoc !

Ok. Ostatnia rzecza o jaka chcialbym spytac to jak w tabeli laczaczej ustawic inne pole niz klucze obce w niej zawarte. Bo aby stworzyc powiazanie w tabeli laczacej czytajac dokumentacje, uzyje: collection<<(object, …
Jedyne co przychodzi mi do glowy aby oznaczyc kto jest szefem: @temp = Participant.find(:conditions => ["project_id = ? AND user_id = ?", @project.id, @user.id]) @temp.cheef = true @temp.save
Kod pisalem z glowy, nie testujac go wiec moga byc bledy chodzi mi o sama ideologie. Czy jest moze jakies wygodniejsze i lepsze rozwiazanie?

Pozdrawiam, Michal.

7

Generalnie tak jak napisałeś, ale poczytaj jeszcze o Nested Object Forms
http://ryandaigle.com/articles/2009/2/1/what-s-new-in-edge-rails-nested-attributes

Jeśli odpowiednio wszystko rozplanujesz to w kontrolerze
nie będziesz musiał wykonywać tych zapytań.

8

Dzieki, za pomoc! :slight_smile:

Pozdrawiam, Michał

PS. Eh Chief a nie cheef…

9

Witam, odkopuję trupa, z ponizszym pytaniem:
Mam model o następujących relacjach:

[code]has_many :engineers, :through => :offers
has_many :offers, :accessible => true
has_many :projects, :accessible => true
has_many :bidforms, :accessible => true

has_many :signoffs

belongs_to :contact
belongs_to :user, :class_name => “User”, :creator => true[/code]
Chciałbym dodać kolejną relację do tabeli Users o nazwie ‘rm’
Czy dobrze myślę, że wystarczy
belongs_to :rm, :class_name => “User”, :deafult => null ?

10
  1. Tak, o ile zrobisz odpowiednią migrację (dodasz rm_id do tabeli users).
  2. rm to jest bardzo zła nazwa, od czego to skrót?
11

1)Hmm… to chyba nie rozumiem jednak, albo wkradł się bład propos migracji.
W tabeli Leads chcę zrobić pole rm_id z id rekordu z tabeli Users.
Wydaje mi się, że własnie belongs_to :rm, :class_name => “User”, :deafult => null w modelu Lead doda tą kolumnę właśnie do Lead, a nie do Users, jak wynikałoby z Twojego postu.

Najprościej będzie to lokalnie przetestować - dam znać jak mi poszło

2)rm - resource manager - zmienić nazwę na dłuższą to nie problem :wink:

EDIT:
musiałem się pozbyć :deafult ->null, ale zadziałało tak jak chciałem :slight_smile: