From: James Britt Date: 2005-09-20T08:14:06+09:00 Subject: Re: Some interesting criticisms of rails [NOT dining philosophers] 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. > > 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) > > 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. > > >> 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