From: Ben B. <be...@gr...> - 2005-05-04 18:32:40
|
On 5/4/05 8:54 AM, "Ian Bicking" <ia...@co...> wrote: >> for person in people: >> print person.firstName + ' lives in these cities: ' + >> ','.join([address.city for address in person.addresss]) > No, a join like person.addresses always produces a query. > address.person would not produce a query if the person was in memory. > I've found it far too difficult to keep cache consistency of joins like > this. So this will result in 1+(number of people selected) queries. So there's no way to have the lookup function the same, but have the objects pre-fetched? Is this a limitation of the implementation chosen? I'm just wondering what makes this so difficult, as ActiveRecord already has it and they've only had a few months yet they appear to have caught up and in this aspect passed SQLObject (which has been around almost 2 years?). I've gone through more of the code, and you are right, there's only a metaclass or two, so I'm not going to blame them. :) It is very difficult to go through the code and figure out what is happening though, this is most likely because I'm not familiar enough with the architecture of how SQLObject generates the objects, etc. Is there some brief write-up on the methodology used or architecture so that I can try and fit the code I see in with the architecture in advance, rather than trying to figure out what you were thinking when you wrote it by examining it? > I do most of my programming in threads, so I don't really know. I'd > have to ask you: is there a way to stash objects into a shared memory cache? I looked over memcached which Oleg also mentioned, the Python API is a bit out of date and known to have some issues from what I can see. Is there anyone using Python in a large production environment that has come up with some other way to share objects through a shared memory cache scheme? Thanks, Ben |