You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Guby <gu...@gmail.com> on 2008/04/12 00:26:44 UTC
Loading another object to return in a view!
Dear CouchDB developers and users.
I have another view related question.
What I am trying to do is this:
Every document of type X has stored a reference to document Y. Based
on certain parameters in X i decide whether or not to load and return
document Y from the DB.
The view code I am trying to use looks something like this:
function(doc){
if (doc.class == "OfTypeX" && doc.an_attribute == true){
var db = new CouchDB("mydb");
var doc2 = db.open(doc.id_of_object_Y);
map([doc.another_attribute, doc.id_of_Y], doc2);
}
}
Whenever I include the line "var db = new CouchDB('mydb');" in my view
everything stops... It works perfectly in the Javascript Shell though!
Any ideas?
Aren't you allowed to access the DB directly from a view?
Is there a way to access other documents than the one being passed in
to the view, from a view?
I realize though that these kinds of views might lead to stale data as
the view index doesn't get updated if the document Y gets updated, but
that is all right in my case.
Best regards
Sebastian
Re: Loading another object to return in a view!
Posted by Ralf Nieuwenhuijsen <ra...@gmail.com>.
2008/4/13, Guby <gu...@gmail.com>:
>
> Hi Ralf!
> Thanks for your reply
>
> Approach #3 is basically the one I am using, only that the post_id-user_id
> document is the comment.
> In your approach #3, wouldn't I have to do another trip to the database
> for the blogpost there too?
Yes.
I can't really so a way to use f.ex view collation to fetch both the
> relational document (comment) and the blog post itself with a
> post_id-user_id document when the user id isn't also specified in the blog
> post itself. Because then they can't share a common key.
>
> I hope this can somehow be solved with map/reduce later on.
On restropect, only when a reduce is capable of saying
just-remove-this-key; perhaps by returning 'null' ?
Greetings,
Ralf.
Best regards
> Sebastian
>
>
> On Apr 12, 2008, at 8:53 PM, Ralf Nieuwenhuijsen wrote:
>
> ------=_Part_34546_33031881.1208044393514
> > Content-Type: text/plain; charset=ISO-8859-1
> > Content-Transfer-Encoding: 7bit
> > Content-Disposition: inline
> >
> > I'm no expert, but to me it seems you have some options
> >
> > 1) fetch all posts seperately. (that would be a nice cumaltive roundtrip
> > penalty)
> > 2) store comments in user-profile, instead of separately (annoying)
> > 3) do the relational thing (sorry!), and store a unique document for
> > each
> > relation
> >
> > Solution 3 would mean you put documents for each comment as such:
> >
> > {
> > _id: "post_id-user-id"
> > postid: 9334,
> > userid: 3494,
> > type: "post-user-relationship"
> > }
> >
> > By using post-id-user-id together as the user id you have no risk of
> > duplicating this information. If it doesn't exist you create the
> > document,
> > if it does exist you are just updating it to the exact same values.
> >
> > With this separate relationship document you should be able to pull
> > trick #3
> > for both use-cases.
> >
> > But it's getting really uncomfortable to use such a relational approach
> > here.
> >
> > Greetings,
> > Ralf
> >
> > 2008/4/12, Guby <gu...@gmail.com>:
> >
> > >
> > > Hi Christopher!
> > > I read your post back when you posted it. It is an interesting read.
> > >
> > > I'll try to explain my problem using your blog metaphor, maybe that
> > > makes
> > > it clearer.
> > >
> > > First:
> > > My first attempt was your approach number 1. Storing all the comments
> > > in
> > > the post itself. But I am already getting some 409 Conflicts in my
> > > worker
> > > processes (concurrency conflicts), and that is probably going to
> > > increase
> > > once I get users on my system, so that doesn't seem like a really good
> > > approach.
> > >
> > > Approach #3 is good when you want to get a post and all its associated
> > > comments.
> > > I, on the other hand, am trying to get all the posts that a certain
> > > user
> > > has commented on. If I wanted to use view collation the way you
> > > describe I
> > > would have to store the comment in the post or at least some token
> > > that
> > > indicates that a certain user has commented on a post, and then we are
> > > back
> > > to approach #1 which we are trying to avoid... or am I missing
> > > something?
> > >
> > > Best regards
> > > Sebastian
> > >
> > >
> > > On Apr 12, 2008, at 2:22 PM, Christopher Lenz wrote:
> > >
> > > On 12.04.2008, at 18:13, Guby wrote:
> > >
> > > >
> > > > My first attempt was to store the user ratings in the entry itself,
> > > > > and then use a for loop in the view to map the entry to each user
> > > > > ID, but to
> > > > > store if the user has read the entry or not I would then have to
> > > > > load the
> > > > > whole entry with all its ratings change the value of one flag, and
> > > > > then save
> > > > > it all back. Seems like I would be loading an awful lot of
> > > > > information and
> > > > > wasting a lot of resources(?). Maybe I am trying to save computer
> > > > > cycles at
> > > > > the wrong place. What I ended up doing instead is more a
> > > > > relational database
> > > > > approach:
> > > > >
> > > > > Now I have my entry document which only is the entry itself, and
> > > > > then
> > > > > user_entry documents that have references to the entry, stores the
> > > > > users
> > > > > rating and a flag wether or not it has been read and if the rating
> > > > > passed
> > > > > the users threshold or not. It works perfectly until I want to go
> > > > > from a
> > > > > list of user_entries to a list of entries. If I load a list of
> > > > > user_entries
> > > > > that have a certain rating I have to make a seperate call to the
> > > > > database to
> > > > > load each entry! That is why I tried creating a view that would
> > > > > check the
> > > > > user_entry and the return the qualified entries directly...
> > > > >
> > > > >
> > > > I you haven't read it already, I'd recommend looking at a blog post
> > > > of
> > > > mine that explores this stuff:
> > > >
> > > > <http://www.cmlenz.net/archives/2007/10/couchdb-joins>
> > > >
> > >
>
Re: Loading another object to return in a view!
Posted by Guby <gu...@gmail.com>.
Hi Ralf!
Thanks for your reply
Approach #3 is basically the one I am using, only that the post_id-
user_id document is the comment.
In your approach #3, wouldn't I have to do another trip to the
database for the blogpost there too? I can't really so a way to use
f.ex view collation to fetch both the relational document (comment)
and the blog post itself with a post_id-user_id document when the user
id isn't also specified in the blog post itself. Because then they
can't share a common key.
I hope this can somehow be solved with map/reduce later on.
Best regards
Sebastian
On Apr 12, 2008, at 8:53 PM, Ralf Nieuwenhuijsen wrote:
> ------=_Part_34546_33031881.1208044393514
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> I'm no expert, but to me it seems you have some options
>
> 1) fetch all posts seperately. (that would be a nice cumaltive
> roundtrip
> penalty)
> 2) store comments in user-profile, instead of separately (annoying)
> 3) do the relational thing (sorry!), and store a unique document for
> each
> relation
>
> Solution 3 would mean you put documents for each comment as such:
>
> {
> _id: "post_id-user-id"
> postid: 9334,
> userid: 3494,
> type: "post-user-relationship"
> }
>
> By using post-id-user-id together as the user id you have no risk of
> duplicating this information. If it doesn't exist you create the
> document,
> if it does exist you are just updating it to the exact same values.
>
> With this separate relationship document you should be able to pull
> trick #3
> for both use-cases.
>
> But it's getting really uncomfortable to use such a relational
> approach
> here.
>
> Greetings,
> Ralf
>
> 2008/4/12, Guby <gu...@gmail.com>:
>>
>> Hi Christopher!
>> I read your post back when you posted it. It is an interesting read.
>>
>> I'll try to explain my problem using your blog metaphor, maybe that
>> makes
>> it clearer.
>>
>> First:
>> My first attempt was your approach number 1. Storing all the
>> comments in
>> the post itself. But I am already getting some 409 Conflicts in my
>> worker
>> processes (concurrency conflicts), and that is probably going to
>> increase
>> once I get users on my system, so that doesn't seem like a really
>> good
>> approach.
>>
>> Approach #3 is good when you want to get a post and all its
>> associated
>> comments.
>> I, on the other hand, am trying to get all the posts that a certain
>> user
>> has commented on. If I wanted to use view collation the way you
>> describe I
>> would have to store the comment in the post or at least some token
>> that
>> indicates that a certain user has commented on a post, and then we
>> are back
>> to approach #1 which we are trying to avoid... or am I missing
>> something?
>>
>> Best regards
>> Sebastian
>>
>>
>> On Apr 12, 2008, at 2:22 PM, Christopher Lenz wrote:
>>
>> On 12.04.2008, at 18:13, Guby wrote:
>>>
>>>> My first attempt was to store the user ratings in the entry itself,
>>>> and then use a for loop in the view to map the entry to each user
>>>> ID, but to
>>>> store if the user has read the entry or not I would then have to
>>>> load the
>>>> whole entry with all its ratings change the value of one flag,
>>>> and then save
>>>> it all back. Seems like I would be loading an awful lot of
>>>> information and
>>>> wasting a lot of resources(?). Maybe I am trying to save computer
>>>> cycles at
>>>> the wrong place. What I ended up doing instead is more a
>>>> relational database
>>>> approach:
>>>>
>>>> Now I have my entry document which only is the entry itself, and
>>>> then
>>>> user_entry documents that have references to the entry, stores
>>>> the users
>>>> rating and a flag wether or not it has been read and if the
>>>> rating passed
>>>> the users threshold or not. It works perfectly until I want to go
>>>> from a
>>>> list of user_entries to a list of entries. If I load a list of
>>>> user_entries
>>>> that have a certain rating I have to make a seperate call to the
>>>> database to
>>>> load each entry! That is why I tried creating a view that would
>>>> check the
>>>> user_entry and the return the qualified entries directly...
>>>>
>>>
>>> I you haven't read it already, I'd recommend looking at a blog
>>> post of
>>> mine that explores this stuff:
>>>
>>> <http://www.cmlenz.net/archives/2007/10/couchdb-joins>
Re: Loading another object to return in a view!
Posted by Ralf Nieuwenhuijsen <ra...@gmail.com>.
Just a small note, I might be mistaken, but this could be done more cleanly
using the reduce/combiner functionality that is not implemented yet.
Greetings,
Ralf
2008/4/13, Ralf Nieuwenhuijsen <ra...@gmail.com>:
>
> I'm no expert, but to me it seems you have some options
>
> 1) fetch all posts seperately. (that would be a nice cumaltive roundtrip
> penalty)
> 2) store comments in user-profile, instead of separately (annoying)
> 3) do the relational thing (sorry!), and store a unique document for each
> relation
>
> Solution 3 would mean you put documents for each comment as such:
>
> {
> _id: "post_id-user-id"
> postid: 9334,
> userid: 3494,
> type: "post-user-relationship"
> }
>
> By using post-id-user-id together as the user id you have no risk of
> duplicating this information. If it doesn't exist you create the document,
> if it does exist you are just updating it to the exact same values.
>
> With this separate relationship document you should be able to pull trick
> #3 for both use-cases.
>
> But it's getting really uncomfortable to use such a relational approach
> here.
>
> Greetings,
> Ralf
>
> 2008/4/12, Guby <gu...@gmail.com>:
> >
> > Hi Christopher!
> > I read your post back when you posted it. It is an interesting read.
> >
> > I'll try to explain my problem using your blog metaphor, maybe that
> > makes it clearer.
> >
> > First:
> > My first attempt was your approach number 1. Storing all the comments in
> > the post itself. But I am already getting some 409 Conflicts in my worker
> > processes (concurrency conflicts), and that is probably going to increase
> > once I get users on my system, so that doesn't seem like a really good
> > approach.
> >
> > Approach #3 is good when you want to get a post and all its associated
> > comments.
> > I, on the other hand, am trying to get all the posts that a certain user
> > has commented on. If I wanted to use view collation the way you describe I
> > would have to store the comment in the post or at least some token that
> > indicates that a certain user has commented on a post, and then we are back
> > to approach #1 which we are trying to avoid... or am I missing something?
> >
> > Best regards
> > Sebastian
> >
> >
> > On Apr 12, 2008, at 2:22 PM, Christopher Lenz wrote:
> >
> > On 12.04.2008, at 18:13, Guby wrote:
> > >
> > > > My first attempt was to store the user ratings in the entry itself,
> > > > and then use a for loop in the view to map the entry to each user ID, but to
> > > > store if the user has read the entry or not I would then have to load the
> > > > whole entry with all its ratings change the value of one flag, and then save
> > > > it all back. Seems like I would be loading an awful lot of information and
> > > > wasting a lot of resources(?). Maybe I am trying to save computer cycles at
> > > > the wrong place. What I ended up doing instead is more a relational database
> > > > approach:
> > > >
> > > > Now I have my entry document which only is the entry itself, and
> > > > then user_entry documents that have references to the entry, stores the
> > > > users rating and a flag wether or not it has been read and if the rating
> > > > passed the users threshold or not. It works perfectly until I want to go
> > > > from a list of user_entries to a list of entries. If I load a list of
> > > > user_entries that have a certain rating I have to make a seperate call to
> > > > the database to load each entry! That is why I tried creating a view that
> > > > would check the user_entry and the return the qualified entries directly...
> > > >
> > >
> > > I you haven't read it already, I'd recommend looking at a blog post of
> > > mine that explores this stuff:
> > >
> > > <http://www.cmlenz.net/archives/2007/10/couchdb-joins>
> > >
> > > Cheers,
> > > --
> > > Christopher Lenz
> > > cmlenz at gmx.de
> > > http://www.cmlenz.net/
> > >
> > >
> >
>
Re: Loading another object to return in a view!
Posted by Ralf Nieuwenhuijsen <ra...@gmail.com>.
I'm no expert, but to me it seems you have some options
1) fetch all posts seperately. (that would be a nice cumaltive roundtrip
penalty)
2) store comments in user-profile, instead of separately (annoying)
3) do the relational thing (sorry!), and store a unique document for each
relation
Solution 3 would mean you put documents for each comment as such:
{
_id: "post_id-user-id"
postid: 9334,
userid: 3494,
type: "post-user-relationship"
}
By using post-id-user-id together as the user id you have no risk of
duplicating this information. If it doesn't exist you create the document,
if it does exist you are just updating it to the exact same values.
With this separate relationship document you should be able to pull trick #3
for both use-cases.
But it's getting really uncomfortable to use such a relational approach
here.
Greetings,
Ralf
2008/4/12, Guby <gu...@gmail.com>:
>
> Hi Christopher!
> I read your post back when you posted it. It is an interesting read.
>
> I'll try to explain my problem using your blog metaphor, maybe that makes
> it clearer.
>
> First:
> My first attempt was your approach number 1. Storing all the comments in
> the post itself. But I am already getting some 409 Conflicts in my worker
> processes (concurrency conflicts), and that is probably going to increase
> once I get users on my system, so that doesn't seem like a really good
> approach.
>
> Approach #3 is good when you want to get a post and all its associated
> comments.
> I, on the other hand, am trying to get all the posts that a certain user
> has commented on. If I wanted to use view collation the way you describe I
> would have to store the comment in the post or at least some token that
> indicates that a certain user has commented on a post, and then we are back
> to approach #1 which we are trying to avoid... or am I missing something?
>
> Best regards
> Sebastian
>
>
> On Apr 12, 2008, at 2:22 PM, Christopher Lenz wrote:
>
> On 12.04.2008, at 18:13, Guby wrote:
> >
> > > My first attempt was to store the user ratings in the entry itself,
> > > and then use a for loop in the view to map the entry to each user ID, but to
> > > store if the user has read the entry or not I would then have to load the
> > > whole entry with all its ratings change the value of one flag, and then save
> > > it all back. Seems like I would be loading an awful lot of information and
> > > wasting a lot of resources(?). Maybe I am trying to save computer cycles at
> > > the wrong place. What I ended up doing instead is more a relational database
> > > approach:
> > >
> > > Now I have my entry document which only is the entry itself, and then
> > > user_entry documents that have references to the entry, stores the users
> > > rating and a flag wether or not it has been read and if the rating passed
> > > the users threshold or not. It works perfectly until I want to go from a
> > > list of user_entries to a list of entries. If I load a list of user_entries
> > > that have a certain rating I have to make a seperate call to the database to
> > > load each entry! That is why I tried creating a view that would check the
> > > user_entry and the return the qualified entries directly...
> > >
> >
> > I you haven't read it already, I'd recommend looking at a blog post of
> > mine that explores this stuff:
> >
> > <http://www.cmlenz.net/archives/2007/10/couchdb-joins>
> >
> > Cheers,
> > --
> > Christopher Lenz
> > cmlenz at gmx.de
> > http://www.cmlenz.net/
> >
> >
>
Re: Loading another object to return in a view!
Posted by Guby <gu...@gmail.com>.
Hi Christopher!
I read your post back when you posted it. It is an interesting read.
I'll try to explain my problem using your blog metaphor, maybe that
makes it clearer.
First:
My first attempt was your approach number 1. Storing all the comments
in the post itself. But I am already getting some 409 Conflicts in my
worker processes (concurrency conflicts), and that is probably going
to increase once I get users on my system, so that doesn't seem like a
really good approach.
Approach #3 is good when you want to get a post and all its associated
comments.
I, on the other hand, am trying to get all the posts that a certain
user has commented on. If I wanted to use view collation the way you
describe I would have to store the comment in the post or at least
some token that indicates that a certain user has commented on a post,
and then we are back to approach #1 which we are trying to avoid... or
am I missing something?
Best regards
Sebastian
On Apr 12, 2008, at 2:22 PM, Christopher Lenz wrote:
> On 12.04.2008, at 18:13, Guby wrote:
>> My first attempt was to store the user ratings in the entry itself,
>> and then use a for loop in the view to map the entry to each user
>> ID, but to store if the user has read the entry or not I would then
>> have to load the whole entry with all its ratings change the value
>> of one flag, and then save it all back. Seems like I would be
>> loading an awful lot of information and wasting a lot of
>> resources(?). Maybe I am trying to save computer cycles at the
>> wrong place. What I ended up doing instead is more a relational
>> database approach:
>>
>> Now I have my entry document which only is the entry itself, and
>> then user_entry documents that have references to the entry, stores
>> the users rating and a flag wether or not it has been read and if
>> the rating passed the users threshold or not. It works perfectly
>> until I want to go from a list of user_entries to a list of
>> entries. If I load a list of user_entries that have a certain
>> rating I have to make a seperate call to the database to load each
>> entry! That is why I tried creating a view that would check the
>> user_entry and the return the qualified entries directly...
>
> I you haven't read it already, I'd recommend looking at a blog post
> of mine that explores this stuff:
>
> <http://www.cmlenz.net/archives/2007/10/couchdb-joins>
>
> Cheers,
> --
> Christopher Lenz
> cmlenz at gmx.de
> http://www.cmlenz.net/
>
Re: Loading another object to return in a view!
Posted by Christopher Lenz <cm...@gmx.de>.
On 12.04.2008, at 18:13, Guby wrote:
> My first attempt was to store the user ratings in the entry itself,
> and then use a for loop in the view to map the entry to each user
> ID, but to store if the user has read the entry or not I would then
> have to load the whole entry with all its ratings change the value
> of one flag, and then save it all back. Seems like I would be
> loading an awful lot of information and wasting a lot of
> resources(?). Maybe I am trying to save computer cycles at the wrong
> place. What I ended up doing instead is more a relational database
> approach:
>
> Now I have my entry document which only is the entry itself, and
> then user_entry documents that have references to the entry, stores
> the users rating and a flag wether or not it has been read and if
> the rating passed the users threshold or not. It works perfectly
> until I want to go from a list of user_entries to a list of entries.
> If I load a list of user_entries that have a certain rating I have
> to make a seperate call to the database to load each entry! That is
> why I tried creating a view that would check the user_entry and the
> return the qualified entries directly...
I you haven't read it already, I'd recommend looking at a blog post of
mine that explores this stuff:
<http://www.cmlenz.net/archives/2007/10/couchdb-joins>
Cheers,
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
Re: Loading another object to return in a view!
Posted by Guby <gu...@gmail.com>.
Hi again!
Thanks for taking the time to help me out!
> In addition to Chris' answer: the CouchDB object is just a wrapper
> object that uses AJAX to talk to CouchDB over HTTP. Again, this is
> not available from within views. And while this could be added, it
> sounds more like a hassle than something we'd actually want to
> support.
Yes, you are right... I didn't think of the CouchDB object as a ajax
call, but more as of an direct internal call to the database, but
well, that doesn't make much sense anyway, since all database
interaction goes through the RESTful interface... Now I am
understanding a bit more. I guess I am still quite a bit stuck in my
relational database world :)
> What exactly are you trying to do here? Maybe you are still trapped
> (I know I often am) in the relational world and things could be
> solved in a 'CouchDB way' for you.
What I am trying to do is the following:
I am having entries of different kinds in my database. Each entry has
a automatically calculated rating for each user that differs from user
to user. Based on if that rating is over a certain threshold that also
differs from user to user, and also from entry type to entry type for
each user, the entry gets displayed for the user. Additionally I want
to store a flag for each user that specifies if the user has read the
entry or not.
My first attempt was to store the user ratings in the entry itself,
and then use a for loop in the view to map the entry to each user ID,
but to store if the user has read the entry or not I would then have
to load the whole entry with all its ratings change the value of one
flag, and then save it all back. Seems like I would be loading an
awful lot of information and wasting a lot of resources(?). Maybe I am
trying to save computer cycles at the wrong place. What I ended up
doing instead is more a relational database approach:
Now I have my entry document which only is the entry itself, and then
user_entry documents that have references to the entry, stores the
users rating and a flag wether or not it has been read and if the
rating passed the users threshold or not. It works perfectly until I
want to go from a list of user_entries to a list of entries. If I load
a list of user_entries that have a certain rating I have to make a
seperate call to the database to load each entry! That is why I tried
creating a view that would check the user_entry and the return the
qualified entries directly...
Best regards
Sebastian
Re: Loading another object to return in a view!
Posted by Jan Lehnardt <ja...@apache.org>.
Heya Sebastian,
On Apr 12, 2008, at 01:46, Guby wrote:
> Maybe I wasn't clear.
> It is nothing ajax like.
> What I am trying to accomplish is that when document X is indexed by
> the view server, it maps parts of document Y in addition to itself.
> I have seen the CouchDB class being used in the test suite in the
> couchDB interface, so I thought that was something that also would
> be available in the views?! But it is not?
In addition to Chris' answer: the CouchDB object is just a wrapper
object that uses AJAX to talk to CouchDB over HTTP. Again, this is not
available from within views. And while this could be added, it sounds
more like a hassle than something we'd actually want to support.
What exactly are you trying to do here? Maybe you are still trapped (I
know I often am) in the relational world and things could be solved in
a 'CouchDB way' for you.
Cheers
Jan
--
> Is there no way for a view, indexing the document X, to access the
> database and get some info?
>
> Best regards
> S
>
>
>
>
>
> On Apr 11, 2008, at 8:11 PM, Jan Lehnardt wrote:
>
>> Views do not run in the context of a browser. So you don't have any
>> AJAX features there. The map function gets executed in a very
>> isolated environment.
>>
>> You could hook up a different language interpreter for your views
>> that let's you access external resources, but you'd be pretty much
>> on your own support-wise.
>>
>> Cheers
>> Jan
>> --
>>
>>
>> On 12 Apr 2008, at 00:26, Guby <gu...@gmail.com> wrote:
>>
>>> Dear CouchDB developers and users.
>>> I have another view related question.
>>>
>>> What I am trying to do is this:
>>> Every document of type X has stored a reference to document Y.
>>> Based on certain parameters in X i decide whether or not to load
>>> and return document Y from the DB.
>>>
>>> The view code I am trying to use looks something like this:
>>>
>>> function(doc){
>>> if (doc.class == "OfTypeX" && doc.an_attribute == true){
>>> var db = new CouchDB("mydb");
>>> var doc2 = db.open(doc.id_of_object_Y);
>>> map([doc.another_attribute, doc.id_of_Y], doc2);
>>> }
>>> }
>>>
>>> Whenever I include the line "var db = new CouchDB('mydb');" in my
>>> view everything stops... It works perfectly in the Javascript
>>> Shell though!
>>> Any ideas?
>>> Aren't you allowed to access the DB directly from a view?
>>> Is there a way to access other documents than the one being passed
>>> in to the view, from a view?
>>> I realize though that these kinds of views might lead to stale
>>> data as the view index doesn't get updated if the document Y gets
>>> updated, but that is all right in my case.
>>>
>>> Best regards
>>> Sebastian
>>>
>
>
Re: Loading another object to return in a view!
Posted by Chris Anderson <jc...@mfdz.com>.
On Fri, Apr 11, 2008 at 4:46 PM, Guby <gu...@gmail.com> wrote:
> Is there no way for a view, indexing the document
> X, to access the database and get some info?
>
As Jan said, there's no support in the Javascript view engine for http
queries. This would wreck havoc with view consistency. You can plug in
your own view engine if you really need that functionality. (You could
even run a variant of the Javascript view engine with HTTP support.)
But I doubt you really need to run subqueries. Especially once the
Reduce capability is available, you should be able to accomplish
whatever it is you are thinking of by clever view-key assignment and
reduction. It took me some time to grasp the transforms that can be
accomplished through map/reduce, and I wish I could point to a
resource that lays out the various methods people use to accomplish
particular ends, but I can't think of any. If you keep in mind that
CouchDB's constraints are your friend, you'll find that you may even
come up with a more elegant solution that doesn't involve subqueries
(which would totally break the good properties that CocuhDB does give
you.) Remember that a document can map to multiple view keys, and that
reduce will be fed all view rows that share a given key, and you'll
likely come up with away to accomplish what you are looking for.
Chris
--
Chris Anderson
http://jchris.mfdz.com
Re: Loading another object to return in a view!
Posted by Guby <gu...@gmail.com>.
Maybe I wasn't clear.
It is nothing ajax like.
What I am trying to accomplish is that when document X is indexed by
the view server, it maps parts of document Y in addition to itself.
I have seen the CouchDB class being used in the test suite in the
couchDB interface, so I thought that was something that also would be
available in the views?! But it is not? Is there no way for a view,
indexing the document X, to access the database and get some info?
Best regards
S
On Apr 11, 2008, at 8:11 PM, Jan Lehnardt wrote:
> Views do not run in the context of a browser. So you don't have any
> AJAX features there. The map function gets executed in a very
> isolated environment.
>
> You could hook up a different language interpreter for your views
> that let's you access external resources, but you'd be pretty much
> on your own support-wise.
>
> Cheers
> Jan
> --
>
>
> On 12 Apr 2008, at 00:26, Guby <gu...@gmail.com> wrote:
>
>> Dear CouchDB developers and users.
>> I have another view related question.
>>
>> What I am trying to do is this:
>> Every document of type X has stored a reference to document Y.
>> Based on certain parameters in X i decide whether or not to load
>> and return document Y from the DB.
>>
>> The view code I am trying to use looks something like this:
>>
>> function(doc){
>> if (doc.class == "OfTypeX" && doc.an_attribute == true){
>> var db = new CouchDB("mydb");
>> var doc2 = db.open(doc.id_of_object_Y);
>> map([doc.another_attribute, doc.id_of_Y], doc2);
>> }
>> }
>>
>> Whenever I include the line "var db = new CouchDB('mydb');" in my
>> view everything stops... It works perfectly in the Javascript Shell
>> though!
>> Any ideas?
>> Aren't you allowed to access the DB directly from a view?
>> Is there a way to access other documents than the one being passed
>> in to the view, from a view?
>> I realize though that these kinds of views might lead to stale data
>> as the view index doesn't get updated if the document Y gets
>> updated, but that is all right in my case.
>>
>> Best regards
>> Sebastian
>>
Re: Loading another object to return in a view!
Posted by Jan Lehnardt <ja...@prima.de>.
Views do not run in the context of a browser. So you don't have any
AJAX features there. The map function gets executed in a very isolated
environment.
You could hook up a different language interpreter for your views that
let's you access external resources, but you'd be pretty much on your
own support-wise.
Cheers
Jan
--
On 12 Apr 2008, at 00:26, Guby <gu...@gmail.com> wrote:
> Dear CouchDB developers and users.
> I have another view related question.
>
> What I am trying to do is this:
> Every document of type X has stored a reference to document Y. Based
> on certain parameters in X i decide whether or not to load and
> return document Y from the DB.
>
> The view code I am trying to use looks something like this:
>
> function(doc){
> if (doc.class == "OfTypeX" && doc.an_attribute == true){
> var db = new CouchDB("mydb");
> var doc2 = db.open(doc.id_of_object_Y);
> map([doc.another_attribute, doc.id_of_Y], doc2);
> }
> }
>
> Whenever I include the line "var db = new CouchDB('mydb');" in my
> view everything stops... It works perfectly in the Javascript Shell
> though!
> Any ideas?
> Aren't you allowed to access the DB directly from a view?
> Is there a way to access other documents than the one being passed
> in to the view, from a view?
> I realize though that these kinds of views might lead to stale data
> as the view index doesn't get updated if the document Y gets
> updated, but that is all right in my case.
>
> Best regards
> Sebastian
>