By multiple calls I meant calls from the browser to the server. Right, in my case, now I may one call to get a list of news articles. One potential solution here would be to make the call to get the list of articles, then make another call to get the author for each article. I mentioned exponential growth because this method does grow faster depending on how many nested objects you have and on how many levels deep you have to go. Although one level grows pretty linearly O (1+n*m), where n is the number of top level Models, and m is the second level, it gets worse if you have to traverse further and further down the "rabbit hole", as in the case you mentioned where there would be multiple tiers. Luckily in my case I only have 1 author per news article.
I know this doesn't account for the DB side of things, but obviously it will pose the same problem. I would hope that the underlying framework could possibly take in account for this problem. I know in the Java world, Hibernate does something similar when you turn off lazy loading. The SQL that it generates for selects then attempts to do joins to make one single call to the back-end DB, where possible. Same for the deletes. From your statement, however, it doesn't seem like Django does this. I just wanted to get a general consensus on how people are tackling this in the real world, really. I am personally going to probably go the route of a custom serializer, probably something like this: http://wolfram.kriesing.de/blog/index.php/2007/json-serialization-for-django. On Feb 12, 5:51 pm, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > On Thu, Feb 12, 2009 at 10:17 PM, django_fo...@codechimp.net > > > > <codech...@gmail.com> wrote: > > > I wanted to get the communities thoughts on this subject. I am > > working on a simple site that has news articles, each of which has a > > reference to a User object provided by django.contrib.auth that is the > > author of the news article. This is done right now using the > > following code: > > > class NewsArticle(models.Model): > > subject = models.CharField(max_length=1024) > > author = models.ForeignKey(User) > > body = models.TextField() > > publish_date = models.DateTimeField('date published') > > > As expected, the SQL produced stores the key of the User table in the > > News table. > > > However, when you try to serialize this with the built-in JSON > > serializer, it doesn't traverse the objects. Instead, what you get is > > something like this: > > > [ > > {"pk": 1, > > "model": "news.newsarticle", > > "fields": { > > "body": "This is my very first news article!\r\nIt has some news > > stuff in it", > > "author": 1, "publish_date": "2009-02-09 16:09:22", > > "subject": "My first news article!" > > }}, > > {"pk": 2, > > "model": "news.newsarticle", > > "fields": { > > "body": "Some more news for you...", > > "author": 1, > > "publish_date": "2009-02-11 08:08:36", > > "subject": "Some more news for you" > > } > > }] > > > Notice author just simply prints out the ID. This is due to the lazy- > > nature of the serializers. I have done some reading on the Internets, > > and from what I can tell there are a few options here: > > 1) Write a custom serializer to do this. There are some examples > > out there, but the down side is you have to support the code > > yourself. Compatibility with client-side libraries might be a > > factor. > > 2) Make multiple calls...one to get the News, then one to get each > > author. This could get expensive and cause the interface to > > feel > > sluggish since calls to the backend would grow exponentially. > > These two options are really just the same thing, described at > different levels (unless, when you say "custom serializer", you mean > writing your own JSON library or changing the format in which Django > serializes objects). If you write a custom serializer that follows > relationships, you're really just writing code to make multiple > queries and pass it to the serialization engine. > > This general idea has been proposed in the past (ticket #4656), and > one of these days someone may get around to implementing it. > > If you want to roll this yourself, and you only need to serialize this > model specifically, you actually only need 2 queries - one to retrieve > the News you want, then one to retrieve the Authors related to that > news. The __in operator is your friend here. The general case (which > could have News objects pointing to other News objects, or Author > objects pointing to any other object) may require multiple calls. The > delete() operation does exactly the same object traversal, and while > it isn't cheap, it isn't exponential. > > Yours, > Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
