[Dev] Fwd: Feedback on query doc
twl at osafoundation.org
Wed Feb 18 14:11:47 PST 2004
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
>> 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
> 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
More information about the Dev