On Wed, Jan 7, 2009 at 5:54 PM, Robert Koberg <[email protected]> wrote: > > On Jan 7, 2009, at 10:32 PM, Paul Davis wrote: >> >> >> Remember that views are (theoretically) calculated once per doc. So >> the lookups would be extremely fast once the view is built. >> >> I haven't a good way to explain this yet, but remember that a clever >> view strategy can answer multiple query types. Try not to think of a >> view as a single select statement. I really hate comparing things >> back to SQL, but you should think of a view as being able to answer a >> class of selects that have different values in a where clause. > > given the following doc: > > {"_id": "a", "_rev": "123", "foo": {"bar": {"baz": 1}}} > > and > > http://127.0.0.1:5984/db_name/_view/view_name/by_property?key=["foo.bar";, > "a"] > > to get {"baz": 1} > > I would need to send a key like 'foo.bar' - is that acceptable as a key > value. I mean if the key is used in JS like somedoc[propVar], it won't work. > But perhaps this is done in a different layer (or eval'd in some way?) and > the dot syntax will just work? >
You'd have to build the dot syntax string yourself to get that working, but that shouldn't be overly difficult. > I was hoping for a way to drill into a hierarchy of a known document and > grab what I want however deep it might be from a GET (next, I will ask for > PUT and DELETE :) ). > Partial PUT and DELETE won't ever make it in directly (AFAIK). There are a couple mailing list threads debating the entire issue of partial updates. If there's a development in the JSON community as a whole for a diff format, then the last talk was that there would probably be pretty quick support for a PATCH verb. HTH, Paul Davis > thanks for sticking with me, > -Rob > >> >> >> HTH, >> Paul >
