Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Message-ID: <5654189.557111286313278102.JavaMail.jira@thor>
Date: Tue, 5 Oct 2010 17:14:38 -0400 (EDT)
From: "Paul Joseph Davis (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Subject: [jira] Updated: (COUCHDB-909) Requests to different views at the
 same URL result in the same ETag
In-Reply-To: <26292770.554751286309673721.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/COUCHDB-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Joseph Davis updated COUCHDB-909:
--------------------------------------

    Skill Level: Committers Level (Medium to Hard)  (was: Dont Know)

The issue here is that we're currently only using the group signature, update sequence, and optional POST keys. There's nothing currently available to couchdb internals to make a reliable distinction between "same db created same way" or "database deleted and recreated".

We've run into this issue before (in perhaps a slightly different context) but no one has stepped up with a patch to fix it as generally this only affects very small test environment situations.

A proposed solution from earlier conversations was to store a UUID that gets generated when the database is created. This UUID could then be used to detect databases that have undergone delete/create cycles as well as be added to etag generation for objects that don't have enough etag granularity.

The basics for this code would be to write a 40 byte hex string to immediately after creating a database file and then populate that value into the #db{} record whenever the db is opened. There'd also be issues when opening compaction databases that this would have to handle.

> Requests to different views at the same URL result in the same ETag
> -------------------------------------------------------------------
>
>                 Key: COUCHDB-909
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-909
>             Project: CouchDB
>          Issue Type: Bug
>          Components: HTTP Interface
>    Affects Versions: 1.0.1
>         Environment: Tested on OS X 10.6.4
>            Reporter: Tim Hart
>            Priority: Critical
>         Attachments: couch_db_bug_report.tgz
>
>
> Steps to reproduce:
> 1. Create a database, 'test_db'
>  2. Insert design document:
> {
>   "_id":"_design/fetch",
>   "language":"javascript",
>   "views":{
>     "fetchKeys":{
>       "map": "function(doc) {
>         var recordType = doc.type;
>         for(var key in doc){
>           if(/.+_id$/.test(key)){
>             emit({type:recordType, fKey:doc[key]}, null);
>           } 
>         } 
>       }"
>     }
>   }
> }
> 3. PUT document A @ '/test_db/parent_id' : '{"_id":"parent_id", "type":"parent"}'
> 4. POST document B @ '/test_db' : '{"type":"child", "parent_id":"parent_id"}' - Note the assigned ID
> 5. Query the view with "/test_db/_design/fetch/_view/fetchKeys?key%5Btype%5D=child&key%5Bfkey%5D=parent_id&include_docs=true" - Note the resulting ETAg
> 6. Delete the database 'test_db'
> 7. Repeat steps 1 - 5. Note the resulting ETag from the second query is the same as the first, although the results of the query are slightly different (same key, different associated document ID)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.