The metadata includes file revision data (not CouchDB rev), author, notes, etc. Not that large of a doc.
Maybe my use-cases aren't typical, but still seems like the "special" interpretation of / characters in doc ids/list/show/etc requests limits a certain class of problems that CouchDB is otherwise perfect for. (That is, without an additional layer outside of CouchDB which rewrites / into %2F) Thanks On Fri, Apr 9, 2010 at 5:39 PM, Simon Metson <[email protected]> wrote: > What's in the metadata document? File properties, annotations? How big does > that data get per document? > > On 10 Apr 2010, at 00:16, Anh wrote: > >> It's a document about the image, the actual file is in an attachment >> called "file": >> http://couchdb:5984/db/images%2Fhome%2Fblah.png/file >> >> It's easy to suffix "/file" using the new rewrite functionality. But >> still stuck on the encoded directory separators. >> (BTW, it seems it would be great to have true rewrite "functions" in >> CDB, which could use JS operations on text versus just the current >> placeholder approach.) >> >> The dir structure is potentially any depth, and it would be awkward to >> have a db for each root directory. >> The files are interrelated web-content (css, images, etc.), and >> separate replication might be problematic. >> >> Thanks >> >> On Fri, Apr 9, 2010 at 1:50 AM, Simon Metson <[email protected]> >> wrote: >>> >>> Hi, >>> Is http://couchdb:5984/db/images%2Fhome%2Fblah.png a document about >>> the image or the image itself? What about having some of the directory >>> structure in the db names? How deep does the directory need to go? >>> Cheers >>> Simon >>> >>> On 8 Apr 2010, at 20:14, Anh wrote: >>> >>>> No they cannot. >>>> I'm implementing this as a content/file server which allows for nested >>>> directories. >>>> >>>> To support one document per file (important for file revisioning and >>>> other file metadata), document ids like: >>>> >>>> "/images/home/blah.png" >>>> "/images/home/other.png" >>>> >>>> must be URL encoded when requested from CouchDB directly: >>>> http://couchdb:5984/db/images%2Fhome%2Fblah.png >>>> >>>> Since I do not have an app server or Apache in "front off" Couch, I'd >>>> like to know if there's a way to somehow make a direct request CouchDB >>>> that includes one of more "/" characters in a document id. (Rewrite, >>>> redirect, show function, etc.) >>>> >>>> >>>> (P.S. I'm aware that a document's attachments can have "/" in the ids >>>> *but* this means I can only have a single doc for an entire directory >>>> of files, which complicates my revisioning, metadata, etc) >>>> >>>> Thanks >>>> >>>> >>>> On Wed, Apr 7, 2010 at 9:40 PM, Andrew Melo <[email protected]> >>>> wrote: >>>>> >>>>> Is there a specific reason you want to replace the slashes then? the >>>>> users should still be able to access them, right? >>>>> >>>>> On Wed, Apr 7, 2010 at 11:38 PM, 7zark7 <[email protected]> wrote: >>>>>> >>>>>> On 4/7/10 9:15 PM, Randall Leeds wrote: >>>>>>> >>>>>>> On Wed, Apr 7, 2010 at 20:53, 7zark7<[email protected]> wrote: >>>>>>>> >>>>>>>> Hi, is there *any* way within CouchDB to modify a GET URL to replace >>>>>>>> certain >>>>>>>> characters in the document id? >>>>>>> >>>>>>> Probably easiest if you can have the client encode the URL for you. I >>>>>>> don't know if that's acceptable for your use case. >>>>>> >>>>>> Yeah not in my case. This is basically a CMS for static content, and >>>>>> the >>>>>> end users aren't under my immediate control. >>>>>> >>>>>> >>>>>>>> More specifically what I'd like to do is take a request URL that >>>>>>>> contains forward slashes, such as: >>>>>>>> >>>>>>>> a/b/c/d.jpg >>>>>>>> >>>>>>>> and transform this to return a document which has the id: >>>>>>>> >>>>>>>> a%2Fb%2Fc%2Fd.jpg >>>>>>>> >>>>>>>> etc. >>>>>>>> >>>>>>>> I've tried the rewrite functionality, but doesn't look like it >>>>>>>> supports modifying characters. I've also tried hacky approaches >>>>>>>> like this: >>>>>>>> >>>>>>>> { >>>>>>>> "from": "/file/:a/:b/:c/:d", >>>>>>>> "to": "../../:a%2:b%2:c%2:d" >>>>>>>> } >>>>>>>> >>>>>>>> but the URL doesn't replace this correctly (shows "undefined" in the >>>>>>>> URL) >>>>>>>> >>>>>>>> show functions can't seem to handle rendering attachments as far as >>>>>>>> I can tell. >>>>>>>> >>>>>>>> Any ideas? I know about reverse proxys, etc, just would like to >>>>>>>> avoid additional layers here. >>>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> -- >>>>> Andrew Melo >>>>> >>> >>> > >
