If you only care about whether or not there are children, you could reduce to the count of children for each key.
A On Mon, Feb 1, 2010 at 5:15 AM, Patrick Barnes <[email protected]> wrote: > Thanks, that sounds like should work. The only boundary case for a query to > get the number of children is that if there are no children for that key it > will return a blank result, not a '0' record. > > I thought - hey, if I only cared about presence or absence of children I > could just use the get_children view, passing it key=$parent_id & limit=0 > ... but the view summary (at least in 0.10.0) only returns total row count > and offset, not how many rows would have been returned if limit=0 had not > been present. > > ... okay, having just typed the last paragraph I realise - even if > feasible, that would only work using one key at a time. *yawns* > > But the grouped query makes sense, I'll test it tomorrow. > > -P > > > > On 1/02/2010 10:04 PM, Brian Candler wrote: > >> On Mon, Feb 01, 2010 at 05:43:29PM +1100, Patrick Barnes wrote: >> >>> It looks messy if the node has a little 'expand' icon next to it, >>> though - but there are no actual children below it. Is it possible >>> to create a view that will emit as value whether each node has >>> children? >>> >> >> I think the client needs to make two queries. Under a given node: >> >> 1. Get the list of the children >> 2. Determine whether each child also has children >> >> You can do (2) using a single multi-key query, e.g. >> >> {keys:[c1, c2, c3, ...]} >> >> Using your existing view you'll get all the grandchildren, which you >> probably don't care about but can just check whether there are any or not. >> >> To reduce the size of the returned data you could make a grouped query >> instead. With a suitable reduce function on your view, then you could get >> back a count of the number of children for each child, which might be >> useful >> to display in your UI anyway. >> >> HTH, >> >> Brian. >> >>
