Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of zachary.zolton@gmail.com
 designates 74.125.82.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=sDssjbrff4jD62Rx4A//I3lvpjULsy34ncv56E8Y1e4JhTxL2VO+0KNjyMA74GMiby
         y3stFEWmOTJWT/hQQ+YxrILGkbAFIP25ty1QuOK2hfkmdnK40NaLHTimCFAFdz4HbYm2
         cagwygKBZ06fgiB4Q1QfE1UMW087hal2Fr7hs=
MIME-Version: 1.0
In-Reply-To: <30E4B981-E83E-4E8C-9740-55E2AA36AFAE@netdev.co.uk>
References: <D111C1F9-0C3D-44D5-A90B-37F57B4EAEE2@netdev.co.uk>
	<30E4B981-E83E-4E8C-9740-55E2AA36AFAE@netdev.co.uk>
From: Zachary Zolton <zachary.zolton@gmail.com>
Date: Fri, 30 Jul 2010 14:06:17 -0500
Message-ID: <AANLkTimKR=ONkJhFZxKeAmukQovyiGth_7AQyBz45e2t@mail.gmail.com>
Subject: Re: Linked Documents
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

John,

Short answer: No, during validation you'll need to make decisions
solely based on the contents of the document and the user.

Generally speaking, all the design doc functions operate in that
manner, where you can't make requests to external resources. If you're
application can live within those constraints, though, CouchDB gives
you quite a bit in return!

When you're app constantly has to validate across multiple documents
you may get the feeling you're fighting an uphill battle, given that
CouchDB only provides atomicity guarantees for single-document
operations.

In reality, it's often "good enough" to perform some client-side
application checks on your data before sending it to the database.
Alternatively, you could build a backend program to monitor your data,
and even build functionality for your system's expert users to rectify
invalid data after-the-fact.

My point however is that when deciding CouchDB (or any datastore, for
that matter!) you'll need to evaluate how well your app's requirements
fit within the database's constraints, and how much you'll need to
build into your systems to support its operation. CouchDB works well
when each independent document carries with it all the info it needs.


Cheers,

Zach


On Fri, Jul 30, 2010 at 1:32 PM, John <john.logsdon@netdev.co.uk> wrote:
> Hi again
>
> I didn't get any replies to this post so I'm going to boil it down to a s=
imple question which hopefully someone knows the answer to (positive or neg=
ative!):
>
> Can the Design Document functions make database queries?
> e.g. If the validation method is being executed and it wants to check a r=
eferenced id, can that be done?
>
> Regards
>
> John
>
> Begin forwarded message:
>
>> From: John <john.logsdon@netdev.co.uk>
>> Date: 26 July 2010 22:38:17 GMT+01:00
>> To: user@couchdb.apache.org
>> Subject: Linked Documents
>>
>> Hi
>>
>> I have a Use Case where I store an Account Tree in the database. Each Ac=
count Node points to its parent and I can resolve the tree using several da=
tabase =A0queries by getting the account then its parent then its parents p=
arent, I guess you get the idea!
>>
>> We store data as attributes in these account objects and inheritance is =
used to easily propogate attributes down the account tree and override them=
 at each node as required.
>>
>> I've just been reading the wiki and seen a nice feature where I can emit=
 index entries with foreign id's which is great if I already know them in t=
he doc my map function is working on however I would prefer to just referen=
ce my parent and then *follow* that link to get the parent doc and retrieve=
 it's parent id from there.
>>
>> So I guess what I'm trying to ask for here is whether I can retrieve ano=
ther =A0document from the database, by id, from within the map function in =
a view?
>> I can see lots of other places in our design where this could be really =
useful especially for validation of referenced id's within documents.
>>
>> Thanks
>>
>> John
>
>