This content has been marked as final. Show 3 replies
Model.removeAll() does a truncate (DDL operation) behind the scenes, whereas model.remove(model.listStatements()) does a DML. This might explain why free space is reclaimed immediately in the tablespace with model.removeAll().
Hello, we have similar issue with our project. Two questions about this:
First, if you need to run some jena code with a user with no ddl privileges over the model, and just can use model.remove(model.listStatements()), is there any way to force the release of that space in the tablespace?
And second, when we execute many times a test very similar to the one above, we notice the space used by the tablespace grows indefinitely. The number of rows in the table of the model continues to grow, even when the triples stored in each execution are exactly the same!! We know the cleanup can be forced calling SEM_APIS.REMOVE_DUPLICATES, but is there another way of having Oracle do this automatically?
If you mean that your tablespace has grown from adding new triples and you want to reduce the size of the datafiles after removing those triples, then you could shrink the tablespace as discussed here:
About the second question, the number of rows in the application table grows because duplicates are allowed in the application table. Note that you will not get any duplicates back when you query them using SEM_MATCH of Jena Adapter - this is because of the RDF semantics - however, they are stored in the application table nevertheless. If you want to avoid storing duplicates, you could create a unique index on the application table.