couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sven Helmberger (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COUCHDB-217) Store Revision of Attachments
Date Sat, 24 Jan 2009 08:53:59 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666860#action_12666860
] 

Sven Helmberger commented on COUCHDB-217:
-----------------------------------------

ok, that's unfortunate.. 

How about not using the document rev but creating a new uuid value just for the new attachment
and storing that?

I could still use the UUID to find out that the attachment has changed and you could still
use that UUID as Etag.

> Store Revision of Attachments
> -----------------------------
>
>                 Key: COUCHDB-217
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-217
>             Project: CouchDB
>          Issue Type: Improvement
>            Reporter: Sven Helmberger
>
> I'm writing some multi-app hosting thing and besides using couchdb as database it also
stores all images and stylesheets and scripts etc for the applications as attachments. I have
one couchdb database per app and
> store all resources on a single document to keep the same relative hierarchical structure
I have in my apps.
> I can now fetch that document and use it to quickly find out the name, lenght and content-type
of all my attachments. When the document revision changes I know that at least one of the
attachments has changed, but I don't know which.
> Wouldn't it be possible to store the revision in which the attachment was created with
the attachment?
> _attachments could then contain these revisions as additional property and couchdb could
use that revision as ETag when serving the attachment content which would be better than using
the documents revision like it is now. 
> I don't know the code, so I don't know wheter this is possible..

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


Mime
View raw message