# Object graphs **URL:** \ **Category:** Rails\ **Created:** [December 21, 2005, 2:03pm UTC](https://www.ruby-forum.com/t/object-graphs/74179 "2005-12-21T14:03:34Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![princenamor](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/c0e974/32.png) [@princenamor](https://www.ruby-forum.com/u/princenamor)\ **Post date:** [December 21, 2005, 2:03pm UTC](https://www.ruby-forum.com/t/object-graphs/74179/1 "2005-12-21T14:03:34Z")
Guys, I’m designing an application currently that will ultimately be implemented in either Rails or php5 (most likely Rails). While I’ve coded many PHP (pre-5) applications in the past, OO support was so weak that my OO designs were never truly divorced from the limitations of the language, thus I never had to consider this problem. The question is: how does Rails (and how do PHP5’ers now that PHP5 has good enough OO support to make building large object graphs feasible) persist large object graphs between requests? In other words, say I have around 15 model classes where each class is composed somehow by at least one other in the group, and that some of these classes are persisted by ORM. On the first request, loading one particular object might cause objects of all these classes to be either loaded from the ORM store or instantiated. If the same web user issues a request two seconds after this one that would require the same objects, am I forced to reload everything again, or is there a better way? I know serialization might work for this, but I’m concerned about overhead. Thanks in advance for your help in clarifying this dilemma. John ---
**Author:** ![princenamor](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/c0e974/32.png) [@princenamor](https://www.ruby-forum.com/u/princenamor)\ **Post date:** [December 21, 2005, 5:29pm UTC](https://www.ruby-forum.com/t/object-graphs/74179/2 "2005-12-21T17:29:11Z")
Hi, On Dec 21, 2005, at 8:14 AM, John W. wrote: > Guys, > > I’m designing an application currently that will ultimately be > implemented > in either Rails or php5 (most likely Rails). [snip] > issues a > request two seconds after this one that would require the same > objects, am > I forced to reload everything again, or is there a better way? This scenario is pretty much exactly why I wrote xampl (first in Java, then in Lisp, now in Ruby). There is a GPL version on rubyforge: [http://rubyforge.org/projects/xampl/](http://rubyforge.org/projects/xampl/). Well, there’s a lot more to the ‘why xampl’ than that but anyway… I’m working (in production but being actively developed) on a relatively simple application that has something like 42 classes (and who knows how many instances) that might get dragged in as you describe. I have a larger application in production that has 120 such classes, and another with 201. These are all Java applications as it happens. I also have a Common Lisp application with 49 classes like that. I’ve only been prototyping in Ruby so far, but I think the smaller applications (40-49) would be more than feasible in Ruby. I’m not completely sure how these would translate to tables in ActiveRecord because I don’t know how many inter-object relationships are supported by these applications (but there would be a lot, certainly no less than 3 or 4 per object). I am just now starting to look at how I might integrate xampl with Rails. There are a number of possibilities that I can see, the easiest (you can do this today) is to just use it for the Model but you’ll lose the whole scaffolding part of Rails. This is an unpleasant trade-off, and one that I think should be at least partially addressable through modifications to xampl alone. On the other hand, I would have a very difficult time using the CRUD approach (even with all the help Rails provides) with the kinds of applications I write, so I’d unhappily be willing to give up on the scaffolding. As an alternative, you might look into how to use Madeleine with Rails (instiki does this). This might be a good solution if your application fits the constraints of Madeleine. And of course, there could be other solutions. As I say, I’m new to Rails. I plead ignorance if I’ve ignored anything 🙂 > I know serialization might work for this, but I’m concerned about > overhead. I wouldn’t recommend this. You’d be _far_ further ahead trying to use the AR model as it now stands, or working with xampl. > Thanks in advance for your help in clarifying this dilemma. Hmm. I don’t know if I clarified anything 🙂 Cheers, Bob > John > > * * * > > Rails mailing list > removed\_email\_address@domain.invalid > [http://lists.rubyonrails.org/mailman/listinfo/rails](http://lists.rubyonrails.org/mailman/listinfo/rails) * * * Bob H. – blogs at [http://www.recursive.ca/hutch/](http://www.recursive.ca/hutch/) Recursive Design Inc. – [http://www.recursive.ca/](http://www.recursive.ca/) Raconteur – [http://www.raconteur.info/](http://www.raconteur.info/) ---
**Author:** ![princenamor](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/c0e974/32.png) [@princenamor](https://www.ruby-forum.com/u/princenamor)\ **Post date:** [December 21, 2005, 4:25pm UTC](https://www.ruby-forum.com/t/object-graphs/74179/3 "2005-12-21T16:25:33Z")
Hi Am 21.12.2005 um 14:14 schrieb John W.: > In other words, say I have around 15 model classes where each class is > composed somehow by at least one other in the group, and that some of > these classes are persisted by ORM. On the first request, loading one > particular object might cause objects of all these classes to be > either > loaded from the ORM store or instantiated. If the same web user > issues a > request two seconds after this one that would require the same > objects, am > I forced to reload everything again, or is there a better way? Of course you could store an object graph in the session but I would propably try not to do this. First, you might get huge sessions (i objects \* n bytes \* m parallelly logged in users). Second, you would have to care about synchronization and this is a nontrivial problem IMO. Third, ActiveRecord is a nice way to edit data in a database object orientated but its strong point is the tight integration into RoR rather than being a good ORM layer IMO. Also consider the “relations cannot be set without updating the database” problem I described in this ticket: http:// [dev.rubyonrails.org/ticket/2238](http://dev.rubyonrails.org/ticket/2238) - the ticket also has a proposal for a change to ActiveRecord that would make such things work. Note that incorporating the changes proposed there would require much work (and insight into the internal workings of ActiveRecord) and none of the RoR core developers has shown any particular interest in this ticket or commented on it. There seems to be some interest in the community, though, judging from the number of cc entries. You might want to reconsider your application design. RoR is not about managing huge object graphs in memory over simple requests but about solving your problem with less code. It kind of pushes you into simplifying a lot. This is a good thing IMO since it makes you see bloated sections of your design that you might have missed and wasted time into. Regards Manuel H. ---
**Author:** ![princenamor](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/c0e974/32.png) [@princenamor](https://www.ruby-forum.com/u/princenamor)\ **Post date:** [December 22, 2005, 4:50pm UTC](https://www.ruby-forum.com/t/object-graphs/74179/4 "2005-12-22T16:50:00Z")
Thanks guys…definitely gives me something to look at. The fact that I got responses at all illustrates what appears to me to be a significant difference between the PHP and Rails community: in my opinion, the average Rails developer is more experienced than the average PHP developer. Now, I’m stretching it a bit to make this assertion, but I do believe it’s true. I posted this same question on the #php irc channel and got a response that was the equivalent of “object graphs? object graphs are teh suck”. To be fair, I probably should’ve posted the question on the php mailing list. I’m sure there are more experienced folks there. Thanks again, John