[Dev] Fwd: Feedback on query doc

[Ted Leung]

Here's the remainder of our exchange.

Begin forwarded message:

> From: Ted Leung <twl at osafoundation.org>
> Date: February 18, 2004 2:07:45 PM PST
> To: Chih-Chao Lam <chao at osafoundation.org>
> Subject: Re: Feedback on query doc
>
>
> On Feb 17, 2004, at 10:51 PM, Chih-Chao Lam wrote:
>
>> Hi Ted,
>>
>> Thanks for your detailed reply. It's been a crazy day of meetings for 
>> me, so only got a chance to read your reply in detail now.
>>
>> Definitely feel free to send our exchange to Dev or anywhere you 
>> think is helpful. Feel free to edit my questions or comments too if 
>> that will make the exchange clearer. Here're a few more comments:
>
> I'll probably forward the messages, and this reply as well.
>
>>
>>
>>>> 	- #9: What's attribute traversal?
>>>
>>> All managers who have an Employee who's Spouse's dog is a Golden 
>>> Retriever.  If you start with a manager item, you "reach" the dog 
>>> via traversing attributes of items.
>>>
>> This sounds like a sophisticated feature but is this simple to 
>> implement or is there an important use case for this feature? I can't 
>> think of one off hand.
>
> For people implementing parcels that use a highly linked content 
> model, this is a very useful feature to have.  A naive (low 
> performance) implementation is not very hard.  We can worry about 
> speeding it up later.
>
>>
>>>> 	- #12: Even as results are produced incrementally, the total 
>>>> result set size should be known at the beginning of the iteration, 
>>>> right? [is this what #8 is referring to?]
>>>
>>> Not necessarily.  If you've never run the query against the 
>>> repository before, you don't really know how many items will satisfy 
>>> it.
>>>
>> I think it's useful for some queries to know the result set size even 
>> when only the first iteration of results are sent back. This could be 
>> used to provide feedback to the user on the result set of a complex 
>> query (e.g. adjusting scrollbar values, even with just the first 
>> iteration of the result).
>
> The problem is that you don't want to generate the whole result (which 
> is the only way to know the true size) before you start returning 
> items to the consumer of the result set.   So it's a tradeoff between 
> making the latency before you can display short (done by returning 
> items as they are found), and giving good indication of the actual 
> size (done by waiting till you have all the result items so you can 
> tell how big the result is)
>
>>
>>>> - When running python code in the queries, is dynamic scoping 
>>>> supported (as opposed to lexical scoping) for variables?
>>>
>>> I was planning for lexical scoping since that's implied in the 
>>> Python programming model from 2.2 forward.  Do you have a use case 
>>> for dynamic scoping?  This is an area of the proposal that needs to 
>>> be detailed out.
>>>
>> I think I'm conflating several issues together when this question 
>> popped into my head. Basically, I'm thinking of end-user queries. 
>> These could be cut/copy/pasted into several different views or even 
>> shared (say, as ItemCollections) to different repositories. But if 
>> queries contain Python code, then what is the expected result when 
>> they're run in conceivably very different contexts?
>>
>> Maybe, the answer is that Python code queries will never be exposed 
>> to the end-user. But then what is? and how do you translate the 
>> Python code?
>>
>
> Most of the python code will probably be in the form of function call 
> and expression level operators.  Right now, this is vague 
> (intentionally) in the spec, so we can look at this again as I flesh 
> out the document.
>
>> We have not tackled end-user query building and editing from the 
>> design perspective (both through a GUI and/or end-user query syntax). 
>> I was hoping to do this, probably 6-8 weeks later (after nailing 0.4 
>> design-wise). Do you think that would be too late from your 
>> perspective?
>>
>
> I don' think that will be too late, but it's always good to get an 
> idea of the kinds of things you are thinking of (goes both ways)
>
----
Ted Leung                 Open Source Applications Foundation (OSAF)
PGP Fingerprint: 1003 7870 251F FA71 A59A  CEE3 BEBA 2B87 F5FC 4B42