From: Bob Hutchison Date: 2005-09-20T12:38:22+09:00 Subject: Re: Some interesting criticisms of rails [NOT dining philosophers] On Sep 19, 2005, at 7:14 PM, James Britt wrote: > Bob Hutchison wrote: > > >> Hi, >> I'm kind of interested in hearing opinions relating to the >> original question. >> >> > > Same here. I listened to the recording this morning while out > running. > > > > >> I don't know a lot about Rails but I am very interested in >> learning more. I've mucked about with it a bit but nothing >> serious. I definitely formed a good impression of it. >> David Balick provided a URL >> > episode-09.html> to a podcast that contains some criticism of >> Rails (and almost as much praise, so I don't think of this as >> some kind of rant/trashing of Rails). >> It is, I think, difficult to pull the argument out of the >> podcast. David took a shot at it... >> On Sep 16, 2005, at 6:43 PM, David Heinemeier Hansson wrote: >> >> >>> On 9/16/05, David Balick wrote: >>> >>> >>> >>>> In a nutshell, they say that Rails starts to get less >>>> appropriate for apps >>>> with transactions that encompass entities other than just the >>>> database. If >>>> the server side objects also modify the data, and particularly >>>> of the >>>> modified objects then affect other objects, then it can become >>>> very non- >>>> trivial to handle all of that in Rails. >>>> >>>> >>>> >>> >>> >>> >> In my opinion the comments regarding extended transactions is a >> bit of a red herring -- it may well be an issue, but I don't know >> how big in practice (though I'm sure BEA, MS, and IBM want you to >> believe it is a HUGE problem :-). But more importantly, it seemed >> to obscure the real point that was expressed before that. >> >> > > I got the sense that the lack of transactions was the main concern; > that there was no inherent way to assure that all clients were > dealing with the "same" object at any given time, and that one > could not easily update multiple resources (databases, message > queues, what have you) in one transactional shot. > Yes I agree, but there are two levels of this that came up -- at least I think so. The first, and the one that I think they were most concerned with, seemed to be transactions at the application level but that only concerned the db. The second was the extended transactions that include all kinds of stuff beyond the db (as you say, like message queues, and any number of other things like workflow, distributed transactions and stuff like that). If Rails cannot deal with transactions as the application level then it surely can't deal with the extended transactions. As I said, I don't know Rails that well (cursory understanding, at best really) -- does Rails really not have application level transactions? By application level transactions I understand that to mean that if the application pulls a bunch of objects in from the database, modifies some of them, then Rails can guarantee that all of the changed objects have been written successfully or not at all to the db. If Rails cannot do this, then there is a class of applications that Rails cannot support. I find this difficult to believe. > > > >> Here is my take on the argument made: >> 1) They are talking about what they call 'enterprise' >> applications. I think that they're talking about a class of >> applications that do things that are more complex than >> manipulating data in a database (and I think they are including >> in this wide-spread changes in the database in a single >> transaction). I think getting hung up on the term 'enterprise' is >> not a good idea -- everyone can name plenty of enterprise >> applications that primarily manipulate localised data in a database. >> >> > > Quite true. I sort of sniggered when they were talking about > "enterprise" apps, but I also think I understood well enough what > they were saying. It's sort of like when people toss around the > equally vacuous term "Web 2.0"; a bit of reading between the lines > often reveals the actual meaning in the given context (and it's > typically less grand than one might first think). > > > > >> 2) Rails encourages (forces?) the object layer and data layer to >> merge with some negative consequences for that class of >> applications (actually they may not have qualified this and so >> might have expressed it as a universally Bad Thing) >> 3) Rails does not keep track of instances; so that if two >> requests are made for the same object two different copies are >> returned (and what comes with this is a performance question) >> And, of course, raises the possibility of a data integrity concern. >> 4) Rails returns the whole object graph with each request (which >> in certain kinds of applications could pull much more information >> from the DB than necessary) >> 5) Rails does not provide a transaction that can contain more >> than one object retrieval and/or/? write to the DB (at least this >> is what I think they meant) and that there is too much work >> (knowledge maybe?) required to save changes -- this may be >> related to the kind of thing Hal Fulton was getting at in the >> recent KirbyBase thread. >> Now *I* am not making these claims, all *I* am trying to do is >> explain what I heard on the podcast (and it isn't easy), and I >> don't claim that I got *their* arguments correct either. But >> maybe there is enough there to talk about. If not, maybe we >> should just make up our own straw-man issues. >> >> > > That sounds about right, though. > So we have a start :-) > > > >>> Since each request is handled in isolation, >>> >>> >> I'm not sure what you mean by this. >> >> >>> you rarely encounter >>> situations where object changes ripple through with tons of >>> consequences. >>> >>> >> Do you mean that you rarely encounter situations where many >> objects are changed? Rarely as in not in most applications? or >> Rarely as in many applications but only occasionally occurring? >> >> >>> At the end of each request, you'll have to persist your >>> data somehow, so whether that's in a database, Madeleine store, >>> or web >>> service call, I don't see that being all that different. >>> >>> >> I think they are complaining about what you have to do to >> accomplish this in Rails, with the implication that you have to >> do a lot. >> >> >>> >>> Perhaps these guys are just solving different problems. >>> >>> >> Probably (and they called them 'enterprise applications' which >> I've already suggested is a really poor name for them, and >> possibly inflammatory). How would you characterise the problems >> that Rails is really good at, and where it is OK, and where it >> isn't so OK? >> >> >>> But I found >>> the rant to be very abstract and hard to relate to. If you can >>> come up >>> with a concrete example, I'd love to give a more concrete answer to >>> these concerns. >>> >>> >> I find the argument a bit slippery, especially as I try to write >> it down :-) >> >> > > But still, not really a rant; while these guys may have been a bit > obtuse in explaining their concerns, they seem to have reasonable > questions. > > > James > > -- > > http://www.ruby-doc.org - The Ruby Documentation Site > http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML > http://www.rubystuff.com - The Ruby Store for Ruby Stuff > http://www.jamesbritt.com - Playing with Better Toys > > > ---- Bob Hutchison -- blogs at Recursive Design Inc. -- Raconteur --