Ich erwäge, Sequel für etwas meiner haarigeren SQL zu verwenden, die ich in Active Record zu schwer finde.
Gibt es irgendwelche Dinge, auf die ich achten muss, wenn ich Sequel und ActiveRecord für dasselbe Projekt verwende? (Neben den offensichtlichen wie keine AR-Validierungen in der Fortsetzung usw.)
Disclaimer: Ich bin der Sequel-Betreuer.
Sequel ist einfach neben oder anstelle von ActiveRecord zu verwenden, wenn Sie Rails verwenden. Sie müssen die Datenbankverbindung manuell einrichten, ansonsten ist die Verwendung ähnlich. Ihre Sequel-Modelldateien werden in App / Modellen gespeichert und funktionieren ähnlich wie ActiveRecord-Modelle.
Das Einrichten der Datenbankverbindungen ist nicht mühsam, es ist im Allgemeinen eine Zeile in environment.rb, um eine Fortsetzung zu benötigen, und eine Zeile in jeder Umgebungsdatei (development.rb, test.rb, production.rb), um etwas zu tun:
DB = Sequel.connect (...)
Es ist also nur mühsam, wenn Sie 4 Zeilen Setup-Code für langweilig halten.
Die Verwendung von Raw SQL ist im Allgemeinen kein Problem, es sei denn, Sie zielen auf mehrere Datenbanken ab. Der Hauptgrund, es zu vermeiden, ist die erhöhte Ausführlichkeit. Sequel unterstützt die Verwendung von Raw SQL mindestens so einfach wie ActiveRecord, aber die Zeiten, in denen Sie Raw SQL verwenden müssen, sind in Sequel im Allgemeinen recht selten.
BTW, Sequel wird mit mehreren Validierungsplugins ausgeliefert. Das validation_class_methods-Plugin ähnelt ActiveRecord-Validierungen mit Klassenmethoden. Das Plugin validation_helpers hat eine einfachere Implementierung mit Methoden auf Instanzebene, aber beide können ungefähr dasselbe tun.
Wenn Sie bereits ActiveRecord-Code verwenden, der Ihren Vorstellungen entspricht, lohnt es sich wahrscheinlich nicht, den Code auf Sequel zu portieren, es sei denn, Sie möchten Features hinzufügen.
Ich persönlich würde es nicht tun. Es wäre mühsam, nur die Verbindung mehr oder weniger manuell zu verwalten. Ich wäre eher geneigt, wenn Sequel die stärkere Option wäre, auf Rails 3.0 zu warten (oder vielleicht gegen Edge Rails zu entwickeln), wo es relativ einfach sein sollte, ORMs zu wechseln, wenn Yehuda und Co. ihre Sachen richtig machen . Viel mehr Merb-artig als jetzt, zumindest.
Das war die Meinung von DHH zu diesem Thema (ich sage nicht, dass es als Evangeliumswahrheit verstanden werden sollte, Verstand, aber es ist, sozusagen, vom Mund des Pferdes):
Aber ist nicht Sql schmutzig?
Seitdem Programmierer angefangen haben Schicht objektorientierte Systeme an der Spitze von relationalen Datenbanken haben sie kämpfte mit der Frage, wie tief, um die Abstraktion zu führen. Etwas objekt-relationale Mapper suchen Beseitigung der Verwendung von SQL vollständig, Streben nach objektorientierter Reinheit durch Erzwingen aller Abfragen durch ein anderes OO Ebene.
Active Record nicht. Es wurde gebaut auf die Vorstellung, dass SQL weder ist dreckig noch schlecht, nur wortreich in der triviale Fälle. Der Fokus liegt auf die Notwendigkeit beseitigen, mit dem umzugehen Ausführlichkeit in diesen trivialen Fällen aber die Ausdruckskraft für halten harte Abfragen - der Typ SQL war geschaffen, um mit elegant umzugehen.
Deshalb sollten Sie sich nicht schuldig fühlen wenn Sie find_by_sql () verwenden entweder Leistungsengpässe oder hart Abfragen. Beginnen Sie mit dem objektorientierte Schnittstelle für Produktivität und Vergnügen, und das Bad unter der Oberfläche für ein Nah-Metall-Erfahrung, wenn Sie muss.
(Das Zitat wurde hier gefunden, der Originaltext ist auf p334 von < a href="http://www.pragprog.com/titles/rails3/agile-web-development-with-rails-third-edition"> AWDRWR , das "Hängematten" Buch).
Ich denke, das ist vernünftig.
Sprechen wir über etwas, das find_by_sql nicht verarbeiten kann? Oder reden wir über komplexe Nicht-SELECT-Sachen, mit denen execute nicht umgehen kann?
Irgendwelche Beispiele, die wir uns anschauen könnten?
Tags und Links ruby ruby-on-rails activerecord sequel