[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ansel
Subject:    Re: [ansel] Using datatree_id to reference galleries
From:       Ben Chavet <ben () chavet ! net>
Date:       2004-05-26 17:39:24
Message-ID: 20040526123924.619nokk0co08wk8k () mail ! chavet ! net
[Download RAW message or body]

Quoting Jan Schneider <jan@horde.org>:

> Zitat von Ben Chavet <ben@chavet.net>:
>
>>> Ah, you're right. It'd be much simpler if we just stored the
>>> datatree_id in that
>>> field, since that would never change - that way the move would be 
>>> automatic.
>>
>> I'm not sure why, but when I started using the datatree_id instead of the
>> datatree_name in the 'gallery' attribute, postgres would choke on the
>> query.  I
>> waited a good 10 minutes & it was still pegging one of my 
>> processors.  Here is
>> the query:
>>
>> SELECT a1.datatree_id, c.datatree_name FROM horde_datatree c LEFT JOIN
>> horde_datatree_attributes a1 ON a1.datatree_id = c.datatree_id WHERE
>> c.group_uid = 'horde.shares.ansel' AND (a1.attribute_name = 'gallery' AND
>> a1.attribute_value = 2822) AND a1.attribute_name = a1.attribute_name 
>> ORDER BY
>> c.datatree_order, c.datatree_name, c.datatree_id
>>
>> There was only 1 image in the gallery, not sure what was killing it. 
>>  The only
>> difference from using datatree_name is the a1.attribute_value = 2822
>> instead of
>> a1.attribute_value = 'some_gallery_name'.
>>
>> This query is a bit above my head, so does somebody with better SQL 
>> knowledge
>> have any idea?
>
> This query looks fine. Are you sure it was your DB causing the lockup? What
> happens if execute that query directly?

postgres locks when I run that query directly, too.  I even tried 
putting quotes
around the 2822.  I'll keep looking into it, it just doesn't make sense 
why the
same query with a different value would have such different behaviour...

--Ben

[prev in list] [next in list] [prev in thread] [next in thread]