You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Jan Lehnardt <ja...@apache.org> on 2008/04/30 13:30:05 UTC
Re: SVN write-access enabled again...
that should have gone to -dev, sorry.
Jan
--
On Apr 30, 2008, at 13:22, Jan Lehnardt wrote:
> hey, FYI. woo. everybody help crossing fingers!
>
> Begin forwarded message:
>> From: "Norman Maurer" <no...@apache.org>
>> Date: April 30, 2008 1:06:41 PM GMT+02:00
>> To: committers@apache.org, infrastructure@apache.org
>> Subject: SVN write-access enabled again...
>>
>> Hi folks,
>>
>> so eris (SVN) is online again with write-access enabled. So I keep
>> crossing-fingers .....
>>
>> Cheers,
>> Norman
>>
>
>
Re: efficiency of temporary views
Posted by Guby <gu...@gmail.com>.
>> Just as a side note:
>> The views are actually calculated or populated on the first request
>> of the view (or when documents are saved if you activate that (http://wiki.apache.org/couchdb/RegeneratingViewsOnUpdate)
>> ) and not when you save the view document itself.
>
> Just a side note to the side note:
> There is no way to 'activate' on-write view creation :)
:) You are right. It was more out of lack of a better wording.
Seb
Re: efficiency of temporary views
Posted by Jan Lehnardt <ja...@apache.org>.
On Apr 30, 2008, at 15:43, Guby wrote:
>>>
>> Thanks Jan,
>>
>> That certainly makes it easier. I think I understand your warning
>> regarding doubling of the data. Essentially a results of a view are
>> pre-calculated when the view is save? So using the id's to then
>> retrieve
>> the related object would be a lot more efficient in terms of storage.
>> The trade off being multiple requests to get the actual objects?
> Just as a side note:
> The views are actually calculated or populated on the first request
> of the view (or when documents are saved if you activate that (http://wiki.apache.org/couchdb/RegeneratingViewsOnUpdate)
> ) and not when you save the view document itself.
Just a side note to the side note:
There is no way to 'activate' on-write view creation :)
Cheers
Jan
--
>
>
>> Would it be possible to retrieve all the documents in one request. If
>> the id's where continuous it would be easy to use start_key and
>> end_key
>> but what if they are dis-continuous?
> It is actually not necessary that the children's ID's are sequential!
> In Jan's example above you actually get all the children when you
> request the view, and therefore only have to make one request to the
> database to get all the relations!
> The actual ID's of the children doesn't matter to much as they are
> using the parents ID as the key!
>
> Using the following view:
>
>>> function(doc) {
>>> for(var idx in doc.parents) {
>>> map(doc.parents[idx], doc);
>>> }
>>> }
>
> You could get all the children of the parent with ID "foo" like this:
>
> GET /db_name/_view/relations/children_of?key=foo
>
> As long as the design document has the ID "_design/relations" and
> the view the name "children_of"
>
> If you happen to be programming in ruby you can see how I
> implemented this in CouchObject. The changes aren't in the current
> gem yet, but I'll push out a new gem soon. CouchObject now supports
> has_many, has_one and belongs_to relations using the view technique
> above.
> You can get the code from the git repository at http://gitorious.org/projects/couchobject
>
> Best regards
> Sebastian
>
Re: efficiency of temporary views
Posted by Guby <gu...@gmail.com>.
>>
> Thanks Jan,
>
> That certainly makes it easier. I think I understand your warning
> regarding doubling of the data. Essentially a results of a view are
> pre-calculated when the view is save? So using the id's to then
> retrieve
> the related object would be a lot more efficient in terms of storage.
> The trade off being multiple requests to get the actual objects?
Just as a side note:
The views are actually calculated or populated on the first request of
the view (or when documents are saved if you activate that (http://wiki.apache.org/couchdb/RegeneratingViewsOnUpdate)
) and not when you save the view document itself.
> Would it be possible to retrieve all the documents in one request. If
> the id's where continuous it would be easy to use start_key and
> end_key
> but what if they are dis-continuous?
It is actually not necessary that the children's ID's are sequential!
In Jan's example above you actually get all the children when you
request the view, and therefore only have to make one request to the
database to get all the relations!
The actual ID's of the children doesn't matter to much as they are
using the parents ID as the key!
Using the following view:
>> function(doc) {
>> for(var idx in doc.parents) {
>> map(doc.parents[idx], doc);
>> }
>> }
You could get all the children of the parent with ID "foo" like this:
GET /db_name/_view/relations/children_of?key=foo
As long as the design document has the ID "_design/relations" and the
view the name "children_of"
If you happen to be programming in ruby you can see how I implemented
this in CouchObject. The changes aren't in the current gem yet, but
I'll push out a new gem soon. CouchObject now supports has_many,
has_one and belongs_to relations using the view technique above.
You can get the code from the git repository at http://gitorious.org/projects/couchobject
Best regards
Sebastian
Re: efficiency of temporary views
Posted by Jonathan Moss <jo...@tangentlabs.co.uk>.
Jan Lehnardt wrote:
> Hi,
> On Apr 30, 2008, at 14:16, Jonathan Moss wrote:
>> Greetings all,
>>
>> I have been lurking for a couple of weeks now and am about to embark on
>> little project using couch DB and have a couple of questions.
>>
>> I am trying to come up with a flexible way to model an object hierarchy.
>> My current thoughts run something like
>>
>>
>> {
>> _id: xxx
>> _rev: yyy
>> type: something
>> n.e.other: foo
>> parents: ["xxx","xxx"]
>> children: ["yyy","yyy"]
>> }
>>
>> so a simple view (pseudo-code) to get all the children of an object
>> (with id = 123) would be:
>>
>> function(doc):
>> if(doc.parents contains "123"){
>> map(doc._id,doc);
>> }
>> }
>>
>> Obviously this kind of view cannot be persisted as the value if id would
>> need to change for every document in the DB.
>>
>> Would this be terribly in-efficient as it would have to be a temporary
>> view or am I missing a trick?
>> Could I do something cunning with the key
>> field in the map function and the start/end_key get params?
>
> Yeah :)
> Do:
>
> function(doc) {
> for(var idx in doc.parents) {
> map(doc.parents[idx], doc);
> }
> }
>
> and then you can use the startkey parameters to get all docs
> that have the parent "123". The Same for children and and
> anything else you need.
>
>
>> This also extends to the question of how to deal with running
>> getChildren and only returning those of a specific 'type' e.g.
>>
>> if(doc.type = 'atype' && doc.parents contains "123"){
>> ...
>> }
>
> map([doc.parent[idx], doc.type], doc);
>
> You can have complex JSON structures as the key that
> allows you to collate by more than one attribute.
>
> Don't be shy of adding more views :)
>
> Beware though, at the moment you store the full doc
> in the view, effectively doubling data. If that is okay
> for you application and amount of data, never mind.
> If you want to be a tad more conservative, store NULL
> as the map value and retrieve only the document ids
> from the view and the document data with subsequent
> requests. Trade-offs and all that.
>
>
> Cheers
> Jan
> --
>
>
Thanks Jan,
That certainly makes it easier. I think I understand your warning
regarding doubling of the data. Essentially a results of a view are
pre-calculated when the view is save? So using the id's to then retrieve
the related object would be a lot more efficient in terms of storage.
The trade off being multiple requests to get the actual objects?
Would it be possible to retrieve all the documents in one request. If
the id's where continuous it would be easy to use start_key and end_key
but what if they are dis-continuous?
Thanks again,
Jon
Re: efficiency of temporary views
Posted by Jan Lehnardt <ja...@apache.org>.
Hi,
On Apr 30, 2008, at 14:16, Jonathan Moss wrote:
> Greetings all,
>
> I have been lurking for a couple of weeks now and am about to embark
> on
> little project using couch DB and have a couple of questions.
>
> I am trying to come up with a flexible way to model an object
> hierarchy.
> My current thoughts run something like
>
>
> {
> _id: xxx
> _rev: yyy
> type: something
> n.e.other: foo
> parents: ["xxx","xxx"]
> children: ["yyy","yyy"]
> }
>
> so a simple view (pseudo-code) to get all the children of an object
> (with id = 123) would be:
>
> function(doc):
> if(doc.parents contains "123"){
> map(doc._id,doc);
> }
> }
>
> Obviously this kind of view cannot be persisted as the value if id
> would
> need to change for every document in the DB.
>
> Would this be terribly in-efficient as it would have to be a temporary
> view or am I missing a trick?
> Could I do something cunning with the key
> field in the map function and the start/end_key get params?
Yeah :)
Do:
function(doc) {
for(var idx in doc.parents) {
map(doc.parents[idx], doc);
}
}
and then you can use the startkey parameters to get all docs
that have the parent "123". The Same for children and and
anything else you need.
> This also extends to the question of how to deal with running
> getChildren and only returning those of a specific 'type' e.g.
>
> if(doc.type = 'atype' && doc.parents contains "123"){
> ...
> }
map([doc.parent[idx], doc.type], doc);
You can have complex JSON structures as the key that
allows you to collate by more than one attribute.
Don't be shy of adding more views :)
Beware though, at the moment you store the full doc
in the view, effectively doubling data. If that is okay
for you application and amount of data, never mind.
If you want to be a tad more conservative, store NULL
as the map value and retrieve only the document ids
from the view and the document data with subsequent
requests. Trade-offs and all that.
Cheers
Jan
--
efficiency of temporary views
Posted by Jonathan Moss <jo...@tangentlabs.co.uk>.
Greetings all,
I have been lurking for a couple of weeks now and am about to embark on
little project using couch DB and have a couple of questions.
I am trying to come up with a flexible way to model an object hierarchy.
My current thoughts run something like
{
_id: xxx
_rev: yyy
type: something
n.e.other: foo
parents: ["xxx","xxx"]
children: ["yyy","yyy"]
}
so a simple view (pseudo-code) to get all the children of an object
(with id = 123) would be:
function(doc):
if(doc.parents contains "123"){
map(doc._id,doc);
}
}
Obviously this kind of view cannot be persisted as the value if id would
need to change for every document in the DB.
Would this be terribly in-efficient as it would have to be a temporary
view or am I missing a trick? Could I do something cunning with the key
field in the map function and the start/end_key get params?
This also extends to the question of how to deal with running
getChildren and only returning those of a specific 'type' e.g.
if(doc.type = 'atype' && doc.parents contains "123"){
...
}
Thanks for any help you can give me,
Jon