[
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.
