>>> Hi,
>>> I'm a new user of Jena and i'm french so sorry for my english !
>>> I noticed the same thing as him :
>>>
http://stackoverflow.com/questions/1...d-jena-dataset
>>>
>>> ("I remove the model from the dataset. Future queries over that model
>>> name reveal that it has successfully been removed. However, the disk
>>> size of the TDB database folder remains the same size, even after
>>> syncing and quitting.")
>>> I wanna know if throw the API or a command line we can "clear" the
>>> repository size.
>>> Because that repository will be use in an professionnal and i do not
>>> want the size on disk stay the same if i delete some triple or graph.
>>>
>>> Thanks for your help.
>>> Sorry for my english, and sorry if i didn't find the solution by my own.
>>> Regards.
>>> A.
>>>
>>
>> No - there isn't a way. The free space is left in the files for later
>> reuse (caveat that restarting causes some of the space to become
>> permanently inaccessible currently).
>>
>> The way to do it is to dump (to NQuads) and restore.
>>
>> Or if it's the whole database, release it from the StoreConnection and
>> delete the files. Except for Windows-64 where there is a long
>> standing Java issue with not being able to release mmap segments.
>>
>> Andy
>>
>>
> Hi andy,
>
> Thanks for your response.
>
> Just to make sure i understand correctly, i have to clean my repository
> by my own
> [/The way to do it is to dump (to NQuads) and restore. Or if it's the
> whole database, release it from the StoreConnection and delete the
> files/] to avoid the disk space use by jena TDB directory grown up
> exponentially if many update are made by the differents clients of my
> application.
If it's a server like Fuseki running, space is reused so there isn't a leak. There is a free block chain but it's not preserved (currently) across restarts of TDB.
> Just for information, my store will contains tens of thousands of triple.
That that large.
> People managing store with billions of triple do the same way to avoid
> this ?
Most uses are not restarting the database repeatedly so they do not encounter the problem. And, realistically, database grow rather than shrink over time.
Andy
>
> Thanks for your time.
>
> Aurelien.