Jak powinna wyglądać akcja do wysłania zapytania do wszystkich użytkowników? Macie jakieś uwagi?
def request
@availible_doctors = User.with_role(:doctors) - shift_entry.shift.on_holidays - [current_user]
@availible_doctors.each do |doctor|
ShiftTrade.create(
shift_entry: params[:shift_entry_id],
requestor: current_user,
acceptor: doctor
)
end
redirect_to doctor_shifts_path, notice: "Request sent"
endPrzy dużej ilości danych warto przerzucić to do delayed_job / resque / sidekiq.
To będzie maksymalnie 20x create.
Czyli sporo. delayed_job / resque / sidekiq
Sporo jak sporo - zależy od ograniczeń serwera, faktycznego czasu wykonania, czy będą np. wysyłane maile, jak często akcja będzie wykonywana, czy to publiczny URL. IMHO nie ma też sensu pchania tego do tła na siłę jeśli będzie to wykonywane tylko kilka razy dziennie przez uprawnionego administratora (szczególnie w sytuacji gdy żadnego z tych narzędzi jeszcze w aplikacji nie ma).
@regedarek powiesz coś więcej?
zmieniłbym nazwę tej akcji, request to actioncontrollerowy obiekt i możesz się kiedyś wpuścić w dziwne błędy taką kolizją
Dokładnie tak zrobiłem, dostałem znany bład stack level too deep 
Będą maile. Także, będę chciał to wrzucić do resque.
Natomiast zastanawiam się czy nie zrefaktorować tego to serialize doctors_ids.
Wieczorem dorzucę więcej kodu.
Mały offtop
availible_doctors czy available_doctors ?
acceptor czy accepter ?
Oto logika którą chcę zaimplementować.
Lekarzy będzie 20.
Każdy z nich widzi kalendarz i wybiera sobie 3 ‘zmiany’ miesięcznie. Kiedy administrator zablokuje dany miesiąc lekarz może tylko wymienić się ‘zmianą’ z innym lekarzem.
Przy kliknięciu ‘Wymień’ wyzwalamy akcję send_request czyli tą którą udostępniłem wyżej.
Powinna ona wysłać email do wszystkich pozostałych lekarzy z zapytaniem o akceptację. Kiedy którykolwiek z nich zatwierdzi, zostaje mu przypisana dana ‘zmiana’. A reszcie znika możliwość akceptowania.
Większość tej logiki mam zaimplementowaną.
Teraz głowie się tylko nad wysłaniem tego zapytania do wszystkich lekarzy. I zaakceptowania go. Wrzucę to później do osobnej klasy. (ShiftTradeRequest)
Shift
has_many :shift_entries
ShiftEntry
has_many :shift_trades
belongs_to :shift
belongs_to :doctor
ShiftTrade
belongs_to :shift_entry
belongs_to :requester, class_name: 'Doctor'
belongs_to :accepter
Zatem problemy są dwa:
Pomyślałem, żeby zamiast tworzyć obiekt ShiftTrade dla każdego lekarza, stworzyć jakiś serialize atrybut gdzie będę przechowywał accepters_ids wszystkich dostępnych lekarzy. I kiedy któryś zaakceptuje, zmienie atrybut expired na true. Tylko jak potem powinienem wyszukiwać dla danego lekarza te shift_trades => ShiftTrade.where(:accepters_ids => current_doctor.id) ?
Wszelkie uwagi i krytyka mile widziana. Nigdy nie implementowałem serialize, mógłby ktoś mi pokazać jak to dobrze zrobić w tym przypadku.
No i planuje dodać resque do wysyłania emaili.
Jaka jest logika w braniu zmian przez lekarzy ? Czy lekarz moze miec 2 lub wiecej zmian pod rzad ?
Przy obecnym rozwiazaniu lekarze beda “spamowani” emailami. Moza utworzyc TradeBoard i na przyklad raz dziennie rozsylac remindera o niezamknietych trejdach.
Obecnie lekarz moze wybrac jakiego slota czasowego chce sie pozbyc, ale czy ma jakikolwiek wplyw jaki slot dostanie w zamian ?
Czy sa mozliwe kolizje, tzn. 2 lub wiecej lekarzy ma zmiane w tym samym czasie ?
Obecnie lekarz rozglasza chec pozbycia/wymiany slota czasowego (request “pasywny”), czy bedzie mozliwosc requestu aktywnego tzn. lekarz A moze wyslac request do innego lekarza B, ze jest zainteresowany danym slotem lekarza B ?
Lekarz może mieć kilka zmian pod rząd, czasem jest do tego zmuszony.
Logika jest taka aby każda zmiana była obsadzona w miesiącu przez jakiegoś lekarza.
Tak, napewno to jest potem do zmiany na trade board i podsumowujące emaile. Notyfikacje emailem zostawiłem na razie w pokoju.
Lekarz powinien po prostu na swoim dashboardzie zobaczyć jakie zmiany są na ‘giełdzie’ i mieć możliwość zaakceptowania ich.
Jeżeli lekarz pozbędzie się jakiegoś slota to nie ma tutaj opcji na otrzymanie innego. Po prostu wybrał 3 sloty ale po zablokowaniu miesiaca chce wymienic jeden to jezeli ktos jego prosbe zaakceptuje zostaną mu 2 i zarobi mniej kasy.
Nie chciałem komplikować ale Shift ma atrybut limit. Jeżeli jest to 2 to na tej zmianie MUSI być dwóch lekarzy. Dla uproszczenia możemy przyjać, że limit jest 1 i wtedy na jednej zmianie MUSI być JEDEN lekarz.
Takie było założenie na początku, dlatego tak to zaimplementowałem, jednak klient zrezygnował z tego. Zatem odpowiedź to NIE(w ciągu najbliższych miesiecy).
Dodam jeszcze jedno: dostępni lekarze to lekarze którzy nie są w dni danej zmiany na wakacjach 
No właśnie, a czy system sam nie zablokuje masowego wysyłania i usunie konta nam ?