On May 14, 2009, at 19:55, Jeremy Evans wrote: <snip> > The errors are due to the use of a string instead of a symbol for key > option. <snip> > The use of a symbol for the option is explicitly mentioned in the > documentation (http://sequel.rubyforge.org/rdoc/classes/Sequel/Model/ > Associations/ClassMethods.html), though I suppose it isn't obvious if > you are coming from ActiveRecord.
[Jeff R] Well now I feel stupid. I was in nose down in the all of the RDoc documentation, and *especially* the association method documentation there, but somehow I missed that the key *must* be a Symbol. :) > In general, Sequel uses ruby > symbols for SQL columns and ruby strings for SQL strings. That a > string works when lazy loading is purely an implementation detail, > it's not by design and it could change in the future. :) [Jeff R] That's fine. Before Rails came out (yes, I've been using Ruby that long) I would've never dreamt that Symbols and Strings would be used interchangeably. Granted, before Rails came along, I only ever used Symbols for their original purpose: a method reference. Rails has done a lot of great things for the Ruby community, but some of its paradigms have managed to make even the best of developers sloppy. :) > I'm glad you chose Sequel for your ORM needs. Could you elaborate on > the reasons you chose Sequel (pros/cons compared to other ORMs)? I'm > always interested in other people's opinions about how Sequel compares > to other ORMs. [Jeff R] We have already written an enterprise healthcare application in Ruby on Rails, and found that the Rails is too constrictive for our needs, and that ActiveRecord is too heavy weight and slow. For the next major version, we've decided to move the application away from Rails, and into a clean Ruby base application of our own design. Our needs were for a fast, though powerful ORM, and an MVC that it happy sitting on-top of our application (as opposed to Rails, which wants your code to be built on top of it). It was a pretty easy sell to get us onto Ramaze. It is lightweight and highly flexible, allowing us to meet our enterprise level goals easier. Our main criteria for choice of ORM was: 1. Speed 2. Features 3. Memory Usage 4. How much of the Ruby classes are extended After trying everything we could get our hands on, it came down to the latest ActiveRecord and the latest Sequel. We liked that we knew and understood AR in large detail (which is an important decider when time=money), and for large queries (~10,000 records) our initial tests were indicating it was faster (though those tests are now considered suspect). Sequel, on the other hand, was compelling. It looked AR- like, but was significantly faster with normal sized queries. As it turns out, one of the biggest marks against it was that the CTO and myself (the architect) didn't like the idea of muddying up the entire application's Symbol class with all these Sequel ORM specific methods. But, since the biggest mark against it turns out to be both optional and not a bid deal anyway, it wasn't hard for us to become convinced us that Sequel was the way to go. :) As I've been learning with Sequel the last couple days, all while trying to solve some of the major ORM related architectural issues, I think we made the right choice. It's internal architecture (building a query via a chain of method calls, and then executing it when ready to get the results) is right down what the CTO and myself were thinking an ORM should really do. Additionally, the fact that Sequel::Model instances are actually a wrapper (as opposed to AR, where they *are* the result), allows us to solve a problem of our own: For reasons too complex to explain now, we needed a way to wrap the results of Sequel in our own wrapper class, and that this must even work on eager loading. It turns out to be trivial to do this: just override Sequel::Model.load to call the original :load and wrap the resulting Sequel::Model instance in a wrapper. Done. -Jeff R Jeremy ----- Jeffrey Reinecke [email protected] blog.paploo.net --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en -~----------~----~----~----~------~----~------~--~---
