I was sceptic, but I tried the link tricks (without restarting couchdb). - with a symbolic link, (softlink, ln -s) * CouchDB does not see the database (not a file). - with hard link (logical, ln- L) * CouchDB effectively see the new db through the link. * removing original file, couchdb still have the db file. * removing the hard link, couchdb should not have it anymore, FALSE!! ==>> detaching is not properly done because couchdb have a cache. /!\ HUGH LIMITATION, file and link have to be on the same partition. It is thus not possible to use this approach for removable filesystem.
Couchdb have a cache, so we can access a db that is offline. Their is a way to see if the db file exist, _all_dbs list only dbs wiche are online (the db file is reachable). /!\ HAVE TO CHECK CURRENT (PENDING) REQUEST before detaching. Alternate, but database statistic on access required, is to lock the DB. The easiest way is to lock de db rejecting all update with "validate_doc_update" and to wait at least 1 seconde before disconnecting the external db file (explanantion: couch db flush every second as in second part in "Batch Mode" paragraphe at http://guide.couchdb.org/draft/performance.html ). So even if batch mode enabled, no data losses (if small data). REQUIERED DB ACCESS STATISTICS, because of following case : However I have tried a big attachement, requiering more than 1 second of file IO (100Mo). This does not result in a direct writting, but a long caching in memory (compressing?) and only a long time (more than 1s, roughtly 30s) after, write is performed to the disk. This is not acceptable to detach the database. A way to monitor db activity would be nice, but so far, I have not found such in the couchDB documentation. Does it exist at least? internally I guesss so. Finally the db file is constantly opened (sudo lsof -r 1 dbfile). if the db can garantee their is no more access (all flushed) this is not really a trouble, but it would be proper to have a clean fcolse. WHY : - I work on a filesystem project, and I would require to mount unmount db like we do with filesystem. Their is a real need to cary the db fs, and not jsut files on standard fs (lacks of information). Regards Le mercredi 20 juin 2012 à 21:19 +0200, Dave Cottlehuber a écrit : > On 20 June 2012 17:59, CDR <[email protected]> wrote: > > I would like to know if such behavior is possible : > > For the runnning instance of couchdb server, ask to attach a db (from > > another directory, even a usb key). Then detach it. > > You could use a soft link to achieve this. Just don't compact the db. > You need to think about where the views will go also. > > I'm assuming that you are not planning to do this on a "real" > server environment so the risk of having incorrect on-disk > formats (they change over releases) and screw-ups due to compacting > and view-building are less of a concern. > > If its a server I'd avoid the monkeying around. Why is this necessary? > > > Also can a view gather data from more than one database. > > No, I don't know if the other forks of CouchDB support this tho. > > > Elsewhere, the solution is to start a new server on another listening > > port, and then query the two servers. Then merge the view result, that > > is getting complicated. > > That's called a JOIN I believe. > > A+ > Dave
