Rozważam użycie Sequel dla niektórych z moich bardziej owłosionych SQL, które uważam za zbyt trudne do stworzenia w Active Record.Sequel w połączeniu z ActiveRecord?
Czy są jakieś rzeczy, o których powinienem wiedzieć podczas używania Sequel i ActiveRecord w tym samym projekcie? (Oprócz oczywistych, takich jak brak walidacji AR w sequelu itp.)
Nota prawna: Jestem opiekunem Sequel.
Sequel jest łatwy w użyciu wzdłuż lub zamiast ActiveRecord podczas korzystania z Rails. Musisz ręcznie skonfigurować połączenie z bazą danych, ale poza tym użycie jest podobne.Twoje pliki modelu Sequel trafiają do aplikacji/modeli i działają podobnie do modeli ActiveRecord.
Konfigurowanie połączeń z bazą danych nie jest uciążliwe, to zazwyczaj jedna linia w environment.rb wymaga kontynuacji, a wiersz w każdym pliku środowiska (development.rb, test.rb, production.rb) robi coś takiego :
DB = Sequel.connect (...)
Więc to tylko uciążliwe, jeśli wziąć pod uwagę 4 linie kodu instalacyjnego żmudne.
Używanie surowego kodu SQL zasadniczo nie stanowi problemu, chyba że kierujesz się do wielu baz danych. Głównym powodem, aby tego uniknąć, jest zwiększona szczegółowość. Sequel obsługuje używanie surowego SQL co najmniej tak łatwo jak ActiveRecord, ale czasy, w których musisz używać surowego SQL, są generalnie dość rzadkie w Sequelu.
BTW, Sequel zawiera wiele wtyczek do sprawdzania poprawności. Wtyczka validation_class_methods jest podobna do sprawdzania ActiveRecord przy użyciu metod klasy. Wtyczka validation_helpers ma prostszą implementację przy użyciu metod na poziomie instancji, ale obie mogą zrobić z grubsza to samo.
Na koniec powiem, że jeśli masz już działający kod ActiveRecord, który robi to, co chcesz, prawdopodobnie nie warto wysyłać kodu do Sequel, chyba że masz zamiar dodawać funkcje.
Osobiście nie zrobiłbym tego. Proste zarządzanie połączeniem mniej lub bardziej byłoby na początku nudne. Byłbym bardziej skłonny, gdybym poczuł, że Sequel jest silniejszą opcją, by trzymać się Rails 3.0 (lub może zacząć rozwijać się przeciwko Edge Rails), gdzie powinno być dość łatwo zmienić ORM, jeśli Yehuda i współpracownik robią to dobrze . O wiele więcej Merbów niż teraz.
To było podjąć DHH w tej sprawie (nie mówię, powinien on być traktowany jako ewangelicznej prawdy, umysł, ale to jest, że tak powiem, z pierwszej ręki):
Ale nieprawdaż t Sql Dirty?
Odkąd zaczął programiści systemów obiektowych warstwy na wierzchu relacyjnych baz danych, oni zmagali się z pytaniem, jak głęboko do uruchomienia abstrakcji. Niektóre relacje obiektowo-relacyjne odwzorowują użytkownika pod kątem całkowicie eliminując użycie SQL, dążąc do czysto zorientowanej obiektowo przez , wymuszając wszystkie zapytania przez inną warstwę OO .
Akta aktywne nie. Zostało zbudowane na podstawie twierdzenia, że SQL nie jest ani brudny, ani zły, tylko w zwykłych przypadkach w . Koncentrujemy się na , usuwając potrzebę radzenia sobie z głosem w tych trywialnych przypadkach, ale zachowując ekspresyjność wokół dla trudnych zapytań typu - typ SQL był stworzony, by radzić sobie z elegancją.
Dlatego nie powinien czuć się winny podczas korzystania find_by_sql(), aby obsłużyć zatorów wykonania lub twardych zapytań. Rozpocznij pracę z interfejsem obiektowym dla wydajności i przyjemności oraz zanurzając się pod powierzchnią, aby uzyskać doznanie w bliskiej odległości od metalu, gdy potrzebujesz.
(Cytat stwierdzono here, oryginalny tekst jest na P334 z AWDRWR, w "hamak" Book).
Myślę, że to rozsądne.
Czy mówimy o czymś, z czym find_by_sql nie może sobie poradzić? Czy też mówimy o złożonych, nieelastycznych rzeczach, z którymi nie można sobie poradzić?
Jakiekolwiek przykłady, na które mogliśmy spojrzeć?
Wszystkie rzeczy, których szukam, działają, a find_by_sql i sanitize_sql_array mogą sobie poradzić. Jestem po prostu trochę niewygodny, mając mocno zakodowany SQL, co jest naprawdę dziwne, ponieważ jestem dość silnym programistą SQL. Podoba mi się jakość LINQ, która wydaje się być kontynuacją sequela. Ale możesz mieć rację, może powinienem nauczyć się akceptować brudzenie się z sql w aplikacji szyny, gdy wydajność jest krytyczna. –
To była interesująca odpowiedź. Szukałem opcji i ta rozmowa była przydatna. – uadrive
Z Sequel możesz również tworzyć własne instrukcje SQL. I nie opierał się na przekonaniu, że SQL jest także brudny lub zły. Ale jest to przydatne w tym przypadku, ponieważ jest bardziej modułowy i można go łatwiej wykorzystać do budowania zapytań, które są częściowo zbudowane ręcznie i częściowo zbudowane za pomocą potężnego narzędzia. –
Mam nadzieję, że nie spotkałem się z anty-Sequelem, to jest moja ulubiona opcja poza Railsami. Nie widzę dużej korzyści z używania dwóch bibliotek razem, tylko po to, aby uzyskać trochę dodatkowej niezależności od platformy, nawet gdy potrzebny SQL jest skomplikowany. Myślę, że to przesada, zwłaszcza jeśli deweloper już wie, co chce napisać. Przerobienie takiego niestandardowego SQL z pewnością nie było największym problemem związanym z bazą danych, z którym miałem do czynienia, gdy musiałem przenosić się z MySQL na Oracle! –
Jakieś wskazówki, jak uzyskać dalszy obiekt db z aktywnego połączenia rekordów? – fotanus