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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
