Witaj na blogu prowadzonym przez Sebana. Spisuję tutaj swoje uwagi na różny temat. Przeważają tematy związane z Internetem, popieranymi przeze mnie rozwiązaniami dotyczącymi wykorzystania komputerów, oraz kilka innych. Przeczytasz tu również recenzje książek IT.
RoR tickets
09 stycznia 2008 | Klucze:
linux,
programowanie,
rails,
ruby,
Techblog
5 komentarzy. trackback
Nie dalej jak dwie godziny temu natrafiłem na problem pisząc dodawanie kontaktów w serwisie opartym o Ruby on Rails. Samo zadanie wydawało mi się raczej proste. HABTM z odwołaniem do samego siebie. Napisałem.
Nie działa. Poszukałem w ,,Rails recipes'' Chada Fowlera, tak samo. Przepisałem na wszelki wypadek. Nie działa. Nadszedł czas by popatrzeć głębiej.
W konsoli irb wpisuję
User.find(3).contacts << User.find(6)
zaglądam w log/developmeng.log i jakież wielkie było moje zdziwienie, gdy zobaczyłem
Dzięki pomocy Comboya z kanału #rubyonrails.pl trafiłem na zgłoszenie błędu
9774: HABTM inserts empty rows. Problem polegał na tym, że do nazywania kolumn używałem symboli zamiast Stringów. Po zamianie działa bez problemu.
Jednak dało mi to trochę do myślenia. Zgłoszenie nastąpiło ponad 3 miesiące temu. W Railsowym tracu priorytet zgłoszenia został zmieniony z dużego na mały. W ciągu tych 3 miesięcy, pojawiły się trzy wydania linii 1.2.x i pojawiło się wydanie 2.0.2 Railsów. A błąd nadal występuje. Nie próbowałem nigdy wczytywać się w źródła ActiveRecorda, ale to chyba nie jest jakiś błąd super trudny do usunięcia? Po premierze dwójki dało się przeczytać opionie, że RoR 2.0 to nic wielkiego. Wielu spodziewało się więcej zmian w kwestii domyślnego railsowego ORM. Chyba jednak praca nad ORM jest odłożona gdzieś na boczne tory. Mam nadzieję, że to się zmieni i ticketów będzie mniej.
KOMENTARZE
24 stycznia 2008 | Tomash |
Nie należy używać HABTM. Po prostu. W dużym skrócie:
http://ruby-rails.pl/rails-10-przykazan/
Czyli należałoby ten kod zrefaktoryzować mniej więcej tak:
has_many :contacts, :through => UsersContacts, :source => :user
UsersContacts jest oczywiście „pełnoprawnym” modelem, z własnym id we własnej tabelce :)
Znowu – api.rubyonrails.org i dokładne obczytanie has_many
Sorry że tak się wcinam, ale znalazłem Cię przez komentarz na moim blogu :)
24 stycznia 2008 | Sebastian Nowak |
Tak to prawda, jest takie zalecenie. Trochę sporne jak dla mnie. Bardziej mi to chodziło by pokazać, że „nazwa_klucza” to coś całkiem innego niż :nazwa_klucza. Co mnie zawiodło i zasmuciło.
24 stycznia 2008 | Tomash |
Oczywiście że tak. Symbol to nie String! Aczkolwiek można łatwo konwertować jeden na drugi :) (to_s, to_sym)
24 stycznia 2008 | Sebastian Nowak |
Oczywiście, że to nie samo. Oczywiście, że duck typing umożliwa łatwą konwersję, ale niespodziewałem się, że symbol nie będzie przyjmowany w tym miejscu.
24 stycznia 2008 | Tomash |
Generalnie w RoR symbole są faworyzowane, chociaż częsta niejawna konwersja przez stosowanie HashWithIndifferentAccess rozleniwia deweloperów ;)
Co do „ticketu” – też zgłosiłem kiedyś, zresztą też a’propos ActiveRecord:
http://dev.rubyonrails.org/ticket/9407
Zauważyłem, że team jest zainteresowany tylko ticketami opisanymi w „edge”.
