[Dev] Re: possible bug in Query

[John Anderson]

Hi Ted:

There's no need to fix the stale args bug anytime soon -- Chandler isn't 
affected by it. I just noticed it while stepping through the code and 
thought you might be interested. And, besides, maybe we should think of 
a way to get rid of args and somehow include them in the query string, 
which makes it easier to store or exchange querys elsewhere in Chandler.

Also, I noticed a bunch of initialization of item attributes in __init__ 
and _warm_init. It seemed simpler (and safer) use initialValue for 
setting all your attributes: _queryString, _resultSet, stale and args. 
It wouldn't surprise me if __init__, onItemLoad and onItemCopy end up 
being identical (just initializing python-only attributes), except for 
when __init__ may want to assign a queryString -- and that particular 
case probably never happens in Chandler, since we almost always 
initialize attributes in parcel XML, so it probably only happens in unit 
test code.

Personally, I'm now thinking it might be better to get rid of onItemCopy 
and onItemLoad altogether and instead have __init__ and warmInit. 
__init__ would only be called when the Item is first created (e.g. not 
called when loaded a subsequent time from the repository). warmInit 
would be called with an argument indicating whether it was being loaded 
or copied, and would also be called after __init__ is called with the 
argument set to load. This makes it easier to use python-only attributes 
on Items, but unfortunately their use is still very error prone so 
discouraging their use seems best.

Finally, I've run into subtle bugs using code like:

if self._resultSet:
   xxxx

which appears in _warm_init, when _resultSet may be non-existent, None, 
or an empty ref collection. So you might make sure you understand each 
of those situations.

Finally, maybe Andi, you and I should do a review of Query when the 0.5 
dust settles.

John

Ted Leung wrote:

>
> On Feb 18, 2005, at 5:43 PM, John Anderson wrote:
>
>> I'm confused by your reply. Seems like you could add a accessor for 
>> setting and getting args like you do with the queryString to solve 
>> the problem I was thinking of -- namely assigning new args to an 
>> existing Query.
>
>
> Ah, ok.  I didn't understand what you wanted -- I thought you wanted 
> something more automatic.  Yes, we could definitely make args a 
> property and invalidate the query whenever you updated the property.  
> I thought you were talking about changing the value reference by the 
> argument.
> I'm out of town tomorrow and Sunday so I won't be able to fix this for 
> you until Tuesday.  If you need it before then, feel free to fix it 
> yourself, otherwise I will be happy to do it first thing Tuesday.
>
>>
>> Also, you verified yesterday that if the argument is an item with an 
>> attribute that is a ref collection then any changes to the ref 
>> collection will cause the query results to update and the subscribers 
>> to be notified, right?
>
>
> Changing items which belong in the query result or leave the query 
> result cause the results to update.  It doesn't matter if those items 
> are in a specific ref-collection or not.   That's different from 
> changing which item/ref-collection is the argument, which is what you 
> asked for above (and which we can do via a property).
>
> Sorry for the confusion,
>
> Ted
>
>>
>> John
>>
>> Ted Leung wrote:
>>
>>> In general, there's no way to tell that the argument has changed.  
>>> If the argument is another query/item collection that might be 
>>> possible.
>>>
>>> On Feb 18, 2005, at 5:08 PM, John Anderson wrote:
>>>
>>>> If you change the args, does the query update the results? If not 
>>>> maybe moving the args into the query string would be the easiest 
>>>> way to fix it.
>>>>
>>>> John
>>>>
>>>>
>>> ----
>>> Ted Leung                 Open Source Applications Foundation (OSAF)
>>> PGP Fingerprint: 1003 7870 251F FA71 A59A  CEE3 BEBA 2B87 F5FC 4B42
>>>
>>
>>
> ----
> Ted Leung                 Open Source Applications Foundation (OSAF)
> PGP Fingerprint: 1003 7870 251F FA71 A59A  CEE3 BEBA 2B87 F5FC 4B42
>