On May 15, 9:11 am, Paploo <[email protected]> wrote: > On May 14, 2009, at 19:55, Jeremy Evans wrote:
First, let me thank you for taking the time to share the reasoning behind your choice of Sequel. It gives me a perspective I don't often get. > [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. :) Don't feel too bad, you aren't the first person to experience that. Other people have requested that an error be raised or it automatically be converted, but I don't think it's a good idea to start checking only certain options. Either all options should be checked or none of the options should be checked, otherwise people get a false sense of security. As I'm too lazy to write code to check all of the options, I think it's best that none of the options be checked. Also, checking options is pretty much against duck typing, so unless you are positive that only certain values are allowable, it's best to avoid. > > 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 definitely against the use of interchangeable strings and symbols in most cases. About the only time I think it makes sense is for things like HTTP param hashes, where the keys in the hash have to be strings and not symbols (otherwise you open yourself to a DOS attack) but you still want to use symbols in your code to make it cleaner. > > 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. Would you be willing to share your test suite? I have a benchmark application I'm working on that works with both ActiveRecord and Sequel and I'd love to get more tests. > 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. Yeah, the modular way Sequel is put together makes customization pretty easy, unlike ActiveRecord which is a bit more monolithic. Anyway, I'm glad you choose Sequel. If you have any questions, please post them here or join #sequel on IRC and I'll be happy to answer them. Thanks, Jeremy --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
