You can delete/remove whatever you are putting into the database.  It's up to your application code to do that.  

For example, if you are recording events, simply tag the events with a timestamp, create an index (btree) on the timestamp and delete old events when you reach a given threshold.  You can collect statistics on a sample set of records to determine your average space requirement and then extrapolate to obtain your upper limit based on your file system limitations (2G), minus some conservative margin.


On 1/22/08, NAVEEN UPADHYAY <> wrote:
Thanks Alex,Kevin for your responses ;^)
 The proposed solutions seem to be quite good.
Only thing i have is my main concern is to purge old data with these .db files and NOT their corruption beyond 2gb.
My only aim is to keep the size of the file always within a limit.
For my driver only the recent data is of use..
So all that i am looking for is a way to purge old data

Will throwing IOExceptions work?
Please suggest some solutions...
Thanks in advance,

On Jan 23, 2008 5:02 AM, Alex Boisvert <> wrote:
On 1/22/08, Kevin Day <> wrote:
Another option would be to have an OOSProvider that could be configured with an instrumentable version for testing (this would be more akin to dependency injection)...  It feels weird to add code to the runtime implementation of a class that forces it to fail...
Any preference? (although I love Brian's idea of using a thumb drive - or maybe even a RAM disk - it's just hard to enforce that stuff in a test suite :-)  )

I understand the weird feeling and I don't have a strong preference.  I think the OOSProvider solution is going to involve more code to achieve the same goal.  If the abstraction isn't needed in the first place, I don't think it's worth the added complexity, meaning adding 4-5 more classes for this test alone.


This email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Jdbm-developer mailing list