On Jul 24, 2013, at 7:11 PM, Richard Schmidt <[email protected]>
 wrote:

> Your idea of keeping all the forecasts for (say) a month in a separate 
> database is neat! We could then simply delete a moths worth of data by simply 
> dropping the relevant database.
> 
> If we first made a copy of the database file before dropping it from couchDB, 
> is it possible to reload the database file copy into another couchDb 
> instance? This would allow us to create an  archive our old data in case 
> someone suddenly decides that they need some very old forecast for auditing 
> reasons.
> 
> 

Yes… in fact you could just use built in replication to do that before you drop 
the db.

> -----Original Message-----
> From: Filippo Fadda [mailto:[email protected]] 
> Sent: Thursday, 25 July 2013 10:14 a.m.
> To: [email protected]
> Subject: Re: Is this use case correct for Couchdb
> 
> I don't know if can be an option for you, but you can use separate databases 
> per forecast, and when don't you need them anymore, you simply delete them.
> 
> CouchDB is an append only database, the only way to remove revisions and 
> deleted documents is through a compaction, but still some information remain. 
> The alternative is purge every single document revision and then run a 
> compaction. But you can't specify an expiring date for your documents. You 
> can do it creating a view in which you store the expiration date, but you'll 
> need a script to purge documents querying the view using as key the 
> expiration date.
> 
> CouchDB doesn't do it automatically.
> 
> -Filippo
> 
> On Jul 24, 2013, at 11:36 PM, Richard Schmidt wrote:
> 
>> We are currently using a Oracle DB. A very expensive, and surprisingly 
>> unreliable way of storing documents. Out super reliable oracle appliance 
>> died and took out business with it. 
>> http://www.nbr.co.nz/article/metservice-promises-mid-morning-return-ck-141662
>> 
>> My gut feeling is that there has to be a better way. 
>> 
>> CouchDb appears to be a perfect fit for our needs except that we don't want 
>> to keep years and years of old data that non-one is interested in.
>> 
>> 
>> 
>> 
>> -----Original Message-----
>> From: Antoine Pitrou [mailto:[email protected]] 
>> Sent: Wednesday, 24 July 2013 8:15 p.m.
>> To: [email protected]
>> Subject: Re: Is this use case correct for Couchdb
>> 
>> Le Wed, 24 Jul 2013 04:59:07 +0000,
>> Richard Schmidt
>> <[email protected]> a écrit :
>>> Thanks for that - is sounds like CouchDb is not a good solution. 
>>> 
>>> Can you recommend a Nosql db that is a better fit?
>> 
>> Why do you want a NoSQL database exactly?
>> 
>> 
> 

Reply via email to