Hehe, but again, there would be a infinite loop in
django\db\models\query.py in get_cached_row
That's because this record in
Here's my patch
=
def get_cached_row(klass, row, index_start, processed={}):
"Helper function that recursively returns an object
Here is my fix for fill_table_cache
===
def fill_table_cache(opts, select, tables,
where,old_prefix,cache_tables_seen,processed = {}):
"""
Helper function that recursively populates the select, tables and
where (in
place) for select
Hi Karen,
On Wed, 2006-08-16 at 06:01 -0700, Karen Tracey wrote:
[...]
> Hmm, in the case where I hit this I don't believe there was a loop in
> the FK relations. The whole model group goes like this:
>
> There are 3 models with no ForeignKeys: Entry, Author, and Publisher
> There are 2 models
Malcolm Tredinnick wrote:
> On Tue, 2006-08-15 at 23:22 -0700, 一首诗 wrote:
> > But if there is a loop in FK relations, it will never stopped!
>
> Wow. Looks like you're right. Good debugging!
Hmm, in the case where I hit this I don't believe there was a loop in
the FK relations. The whole model
Sorry for my mistake!
Because my code is on a PC without Internet Connection, I can not just
coyp and paste the function name.
I've an idea about how to elminate the loop. Add an optional para to
the function which included all processed Foreign Key RelationShip in
the form of
[ [table1Name, C
On Tue, 2006-08-15 at 23:22 -0700, 一首诗 wrote:
> Hah!
>
> I've just found what happened!
>
> django.db.models.fill_cache_table is a function that calls itself until
> it processed all table connected by FK.
For anybody else wondering why they can't this method, it's called
fill_table_cache() (I
Hah!
I've just found what happened!
django.db.models.fill_cache_table is a function that calls itself until
it processed all table connected by FK.
But if there is a loop in FK relations, it will never stopped!
I will see if I could make a simple patch for it.
--~--~-~--~~--
I ran into this also in my initial run through the tutorial trying what
it suggested against my database. I ignored it at the time because I
wasn't really interested in administering things that way, and I
figured I had done something wrong. But this thread made me look at it
again. This is wha
^C dose not help me.
I think it's because django is multithreaded.
But after I have inserted a lot of print in the codes, I found where
the program stopped.
django.db.models.QuerySet.__repr__
called
repr(self._get_data())
And it stopped there. I will trace down to see what happenned tomorrow
On Mon, 2006-08-14 at 09:03 -0700, 一首诗 wrote:
> Hi all,
>
> I met a problem.
>
> When I added a Foreign Key field to list_display, django falls into a
> dead loop and used up memories.
>
> When I removed the field, it's all OK.
>
> I don't think it's my code's problem because I've tested the _
Hi all,
I met a problem.
When I added a Foreign Key field to list_display, django falls into a
dead loop and used up memories.
When I removed the field, it's all OK.
I don't think it's my code's problem because I've tested the __str__
function of both models related by the Foreign Key.
Could
11 matches
Mail list logo
