u1db-discuss team mailing list archive

[James Westby <jw+debian@xxxxxxxxxxxxxxx>]

On Thu, 17 Nov 2011 20:06:29 +0000, Stuart Langridge <stuart.langridge@xxxxxxxxxxxxx> wrote:
> So my question is... what's the index expression to create that index?
> create_index("colour", ["colours"]) seems wrong -- that feels like it
> should put the whole list in the index. What should it be?

My index transformation branch makes exactly that work. I did that as I
thought it was the natural thing to do, and also because I think what
was there before would just break when it encoutered a situation like
this.

It doesn't allow you to do a query directly for "the list is exactly"
but presumably that could be a transformation, or "the list contains"
could be a transformation.

I'm not sure which should be the default, as I'm not sure which would be
most used, and which would be least surprising.

Also, we may want something to treat the list as a set, i.e. "the list
has these elements in any order."

> Extra thing: what if a document also contains
> "phones" [ {"name":"home", "num":"123"},{"name":"work", "num":"456"} ]
> 
> how would I do an index on people who have a work phone number?
> create_index("worknums", [ "phones.name" ]) ? That feels weird; the
> indexer would act differently depending on whether the value of "phones"
> is a dict or a list of dicts. Then again, maybe that's the answer; if a
> part of an index expression resolves to a list, then we do the remainder
> of the index expression for *each item in the list*. This would also
> cope with the above colours example, ignoring my reservations about it
> feeling weird. To me that makes a certain amount of sense. Thoughts?

That's not implemented in my branch I don't think. It currently refuses
to index anything in your example, but I think it could be extended to
do what you say, as a generalisation of the behaviour I explained above.

Thanks,

James