[Mulgara-dev] CRITICAL: Bug fix to Backup operation (off-topic)

[Alex Hall]

This is a little bit off-topic, but related to the blank node discussion 
that occurred on this list a few weeks ago.

Paul Gearon wrote:
> We have a design for a simpler, smaller, and MUCH FASTER 
> string pool that doesn't have any of these issues at all. One of the big 
> differences is that it won't support a delete operation - at least not 
> in normal operation. It does have a compaction operation to use if it 
> starts taking up too much space (we've also talked about running this in 
> the background when the system isn't busy, but that isn't decided), but 
> in most cases it will take up MUCH less space than the current system 
> does, even when nothing ever gets deleted. Because objects don't get 
> deleted and gNodes don't get reused, then it won't be possible for it to 
> lose sync in any way.

As far as I can recall, the main difficulty in maintaining a reference 
to a blank node across transactions lies in the fact that the underlying 
gNode may have been released and reallocated in the meantime. 
Therefore, even though I believe the Connection API allows for a blank 
node to be used in a query constraint (and possibly other places), doing 
so is not guaranteed to give the results you may have expected. 
Certainly the TQL query grammar does not support a blank node in a query 
constraint.

The news that gNodes won't be reused in the new string pool 
implementation seems to suggest that the identity of a blank node 
reference will remain intact across the lifetime of the database.  If 
this is indeed the case, then would we be able to explicitly support the 
use of blank nodes in queries?  That would be a most welcome enhancement.

Alex