Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
Subject: Re: Linked Documents
From: John <john.logsdon@netdev.co.uk>
In-Reply-To: <AANLkTimKR=ONkJhFZxKeAmukQovyiGth_7AQyBz45e2t@mail.gmail.com>
Date: Sat, 31 Jul 2010 10:10:42 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <1B1D0070-971F-4F35-8270-45291D774F45@netdev.co.uk>
References: <D111C1F9-0C3D-44D5-A90B-37F57B4EAEE2@netdev.co.uk>
  <30E4B981-E83E-4E8C-9740-55E2AA36AFAE@netdev.co.uk>
 <AANLkTimKR=ONkJhFZxKeAmukQovyiGth_7AQyBz45e2t@mail.gmail.com>
To: user@couchdb.apache.org

Hi Zach

Ok, I can write a  view that I could query with a set of keys from the =
client, this will work fine.=20
Of course it means there wouldn't be much point doing validation for the =
rest of the document in couchdb which is a shame.

Just so I know, is the omission of ability to reference check simply a =
case of that feature hasnt been enabled or is it a design decision to =
not allow access to the rest of the database from a design document?

Regards

John


On 30 Jul 2010, at 20:06, Zachary Zolton wrote:

> John,
>=20
> Short answer: No, during validation you'll need to make decisions
> solely based on the contents of the document and the user.
>=20
> 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!
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
>=20
> Cheers,
>=20
> Zach
>=20
>=20
> On Fri, Jul 30, 2010 at 1:32 PM, John <john.logsdon@netdev.co.uk> =
wrote:
>> Hi again
>>=20
>> I didn't get any replies to this post so I'm going to boil it down to =
a simple question which hopefully someone knows the answer to (positive =
or negative!):
>>=20
>> Can the Design Document functions make database queries?
>> e.g. If the validation method is being executed and it wants to check =
a referenced id, can that be done?
>>=20
>> Regards
>>=20
>> John
>>=20
>> Begin forwarded message:
>>=20
>>> 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
>>>=20
>>> Hi
>>>=20
>>> I have a Use Case where I store an Account Tree in the database. =
Each Account Node points to its parent and I can resolve the tree using =
several database  queries by getting the account then its parent then =
its parents parent, I guess you get the idea!
>>>=20
>>> 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.
>>>=20
>>> 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 the doc my map function is working on however I would prefer to =
just reference my parent and then *follow* that link to get the parent =
doc and retrieve it's parent id from there.
>>>=20
>>> So I guess what I'm trying to ask for here is whether I can retrieve =
another  document 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.
>>>=20
>>> Thanks
>>>=20
>>> John
>>=20
>>=20