Class PersistentTripleStore

Represents an in-memory view of a triple store provided by an IStorageProvider instance where changes to the in-memory view get reflected in the persisted view.

Inheritance

System.Object

BaseTripleStore

PersistentTripleStore

Implements

INativelyQueryableStore

IUpdateableTripleStore

ITransactionalStore

ITripleStore

System.IDisposable

Inherited Members

BaseTripleStore.IsEmpty

BaseTripleStore.Graphs

BaseTripleStore.Triples

BaseTripleStore.Add(IGraph)

BaseTripleStore.Add(IGraph, bool)

BaseTripleStore.AddFromUri(Uri)

BaseTripleStore.AddFromUri(Uri, bool)

BaseTripleStore.AddFromUri(Uri, bool, Loader)

BaseTripleStore.Remove(Uri)

BaseTripleStore.Remove(IRefNode)

BaseTripleStore.HasGraph(Uri)

BaseTripleStore.HasGraph(IRefNode)

BaseTripleStore.this[Uri]

BaseTripleStore.this[IRefNode]

BaseTripleStore.GraphAdded

BaseTripleStore.GraphRemoved

BaseTripleStore.GraphChanged

BaseTripleStore.GraphCleared

BaseTripleStore.GraphMerged

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.ReferenceEquals(object, object)

object.ToString()

Namespace: VDS.RDF

Assembly: dotNetRdf.dll

Syntax

public sealed class PersistentTripleStore : BaseTripleStore, INativelyQueryableStore, IUpdateableTripleStore, ITransactionalStore, ITripleStore, IDisposable

Remarks

Persistence Behaviour

Note: This is a transactional implementation - this means that changes made are not persisted until you either call Flush() or you dispose of the instance. Alternatively you may invoke the Discard() method to throw away changes made to the in-memory state.

The actual level of persistence provided will vary according to the IStorageProvider instance you use. For example if the DeleteGraph() method is not supported then Graph removals won't persist in the underlying store. Similarily an instance which is read-only will allow you to pull out existing graphs from the store but won't persist any changes.

The Contains() method of the underlying BaseGraphCollection has been overridden so that invoking Contains causes the Graph from the underlying store to be loaded if it exists, this means that operations like HasGraph() may be slower than expected or cause applications to stop while they wait to load data from the store.

SPARQL Query Behaviour

The exact SPARQL Query behaviour will depend on the capabilities of the underlying IStorageProvider instance. If it also implements the IQueryableStorage interface then its own SPARQL implementation will be used, note that if you try and make a SPARQL query but the in-memory view has not been synced (via a Flush() or Discard() call) prior to the query then an RdfQueryException will be thrown. If you want to make the query regardless you can do so by invoking the query method on the underlying store directly by accessing it via the UnderlyingStore property.

If the underlying store does not support SPARQL itself then SPARQL queries cannot be applied and a NotSupportedException will be thrown.

SPARQL Update Behaviour

Similarly to SPARQL Query support the SPARQL Update behaviour depends on whether the underlying IStorageProvider instance also implements the IUpdateableStorage interface. If it does then its own SPARQL implementation is used, otherwise a GenericUpdateProcessor will be used to approximate the SPARQL Update.

Please be aware that as with SPARQL Query if the in-memory view is not synced with the underlying store a SparqlUpdateException will be thrown.

Other Notes

It is possible for the in-memory view of the triple store to get out of sync with the underlying store if that store is being modified by other processes or other code not utilising the PersistentTripleStore instance that you have created. Currently there is no means to resync the in-memory view with the underlying view so you should be careful of using this class in scenarios where your underlying store may be modified.

Constructors

PersistentTripleStore(IStorageProvider, IUriFactory)

Creates a new in-memory view of some underlying store represented by the IStorageProvider instance.

Declaration

public PersistentTripleStore(IStorageProvider manager, IUriFactory uriFactory)

Parameters

Type	Name	Description
IStorageProvider	manager	IO Manager.
IUriFactory	uriFactory	The preferred URI factory to use when creating URIs for this store.

Remarks

Please see the remarks for this class for notes on exact behaviour of this class.

PersistentTripleStore(IStorageProvider)

Creates a new in-memory view of some underlying store represented by the IStorageProvider instance.

Declaration

public PersistentTripleStore(IStorageProvider manager)

Parameters

Type	Name	Description
IStorageProvider	manager	IO Manager.

Remarks

Please see the remarks for this class for notes on exact behaviour of this class.

Properties

UnderlyingStore

Gets the underlying store.

Declaration

public IStorageProvider UnderlyingStore { get; }

Property Value

Type	Description
IStorageProvider

Remarks

Persistence Behaviour

Note: This is a transactional implementation - this means that changes made are not persisted until you either call Flush() or you dispose of the instance. Alternatively you may invoke the Discard() method to throw away changes made to the in-memory state.

The actual level of persistence provided will vary according to the IStorageProvider instance you use. For example if the DeleteGraph() method is not supported then Graph removals won't persist in the underlying store. Similarily an instance which is read-only will allow you to pull out existing graphs from the store but won't persist any changes.

The Contains() method of the underlying BaseGraphCollection has been overridden so that invoking Contains causes the Graph from the underlying store to be loaded if it exists, this means that operations like HasGraph() may be slower than expected or cause applications to stop while they wait to load data from the store.

SPARQL Query Behaviour

The exact SPARQL Query behaviour will depend on the capabilities of the underlying IStorageProvider instance. If it also implements the IQueryableStorage interface then its own SPARQL implementation will be used, note that if you try and make a SPARQL query but the in-memory view has not been synced (via a Flush() or Discard() call) prior to the query then an RdfQueryException will be thrown. If you want to make the query regardless you can do so by invoking the query method on the underlying store directly by accessing it via the UnderlyingStore property.

If the underlying store does not support SPARQL itself then SPARQL queries cannot be applied and a NotSupportedException will be thrown.

SPARQL Update Behaviour

Similarly to SPARQL Query support the SPARQL Update behaviour depends on whether the underlying IStorageProvider instance also implements the IUpdateableStorage interface. If it does then its own SPARQL implementation is used, otherwise a GenericUpdateProcessor will be used to approximate the SPARQL Update.

Please be aware that as with SPARQL Query if the in-memory view is not synced with the underlying store a SparqlUpdateException will be thrown.

Other Notes

It is possible for the in-memory view of the triple store to get out of sync with the underlying store if that store is being modified by other processes or other code not utilising the PersistentTripleStore instance that you have created. Currently there is no means to resync the in-memory view with the underlying view so you should be careful of using this class in scenarios where your underlying store may be modified.

UriFactory

Get the preferred URI factory to use when creating URIs in this store.

Declaration

public override IUriFactory UriFactory { get; }

Property Value

Type	Description
IUriFactory

Overrides

BaseTripleStore.UriFactory

Remarks

Persistence Behaviour

Note: This is a transactional implementation - this means that changes made are not persisted until you either call Flush() or you dispose of the instance. Alternatively you may invoke the Discard() method to throw away changes made to the in-memory state.

The actual level of persistence provided will vary according to the IStorageProvider instance you use. For example if the DeleteGraph() method is not supported then Graph removals won't persist in the underlying store. Similarily an instance which is read-only will allow you to pull out existing graphs from the store but won't persist any changes.

The Contains() method of the underlying BaseGraphCollection has been overridden so that invoking Contains causes the Graph from the underlying store to be loaded if it exists, this means that operations like HasGraph() may be slower than expected or cause applications to stop while they wait to load data from the store.

SPARQL Query Behaviour

The exact SPARQL Query behaviour will depend on the capabilities of the underlying IStorageProvider instance. If it also implements the IQueryableStorage interface then its own SPARQL implementation will be used, note that if you try and make a SPARQL query but the in-memory view has not been synced (via a Flush() or Discard() call) prior to the query then an RdfQueryException will be thrown. If you want to make the query regardless you can do so by invoking the query method on the underlying store directly by accessing it via the UnderlyingStore property.

If the underlying store does not support SPARQL itself then SPARQL queries cannot be applied and a NotSupportedException will be thrown.

SPARQL Update Behaviour

Similarly to SPARQL Query support the SPARQL Update behaviour depends on whether the underlying IStorageProvider instance also implements the IUpdateableStorage interface. If it does then its own SPARQL implementation is used, otherwise a GenericUpdateProcessor will be used to approximate the SPARQL Update.

Please be aware that as with SPARQL Query if the in-memory view is not synced with the underlying store a SparqlUpdateException will be thrown.

Other Notes

It is possible for the in-memory view of the triple store to get out of sync with the underlying store if that store is being modified by other processes or other code not utilising the PersistentTripleStore instance that you have created. Currently there is no means to resync the in-memory view with the underlying view so you should be careful of using this class in scenarios where your underlying store may be modified.

Methods

Discard()

Discards any outstanding changes returning the in-memory view of the store to the state it was in after the last Flush/Discard operation.

Declaration

public void Discard()

Remarks

Persistence Behaviour

Note: This is a transactional implementation - this means that changes made are not persisted until you either call Flush() or you dispose of the instance. Alternatively you may invoke the Discard() method to throw away changes made to the in-memory state.

The actual level of persistence provided will vary according to the IStorageProvider instance you use. For example if the DeleteGraph() method is not supported then Graph removals won't persist in the underlying store. Similarily an instance which is read-only will allow you to pull out existing graphs from the store but won't persist any changes.

The Contains() method of the underlying BaseGraphCollection has been overridden so that invoking Contains causes the Graph from the underlying store to be loaded if it exists, this means that operations like HasGraph() may be slower than expected or cause applications to stop while they wait to load data from the store.

SPARQL Query Behaviour

The exact SPARQL Query behaviour will depend on the capabilities of the underlying IStorageProvider instance. If it also implements the IQueryableStorage interface then its own SPARQL implementation will be used, note that if you try and make a SPARQL query but the in-memory view has not been synced (via a Flush() or Discard() call) prior to the query then an RdfQueryException will be thrown. If you want to make the query regardless you can do so by invoking the query method on the underlying store directly by accessing it via the UnderlyingStore property.

If the underlying store does not support SPARQL itself then SPARQL queries cannot be applied and a NotSupportedException will be thrown.

SPARQL Update Behaviour

Similarly to SPARQL Query support the SPARQL Update behaviour depends on whether the underlying IStorageProvider instance also implements the IUpdateableStorage interface. If it does then its own SPARQL implementation is used, otherwise a GenericUpdateProcessor will be used to approximate the SPARQL Update.

Please be aware that as with SPARQL Query if the in-memory view is not synced with the underlying store a SparqlUpdateException will be thrown.

Other Notes

It is possible for the in-memory view of the triple store to get out of sync with the underlying store if that store is being modified by other processes or other code not utilising the PersistentTripleStore instance that you have created. Currently there is no means to resync the in-memory view with the underlying view so you should be careful of using this class in scenarios where your underlying store may be modified.

Dispose()

Disposes of the Triple Store flushing any outstanding changes to the underlying store.

Declaration

public override void Dispose()

Overrides

BaseTripleStore.Dispose()

Remarks

If you do not want to persist changes you have please ensure you call Discard() prior to disposing of the instance.

ExecuteQuery(string)

Executes a SPARQL Query on the Triple Store.

Declaration

public object ExecuteQuery(string query)

Parameters

Type	Name	Description
string	query	Sparql Query as unparsed String.

Returns

Type	Description
System.Object

Remarks

Persistence Behaviour

Note: This is a transactional implementation - this means that changes made are not persisted until you either call Flush() or you dispose of the instance. Alternatively you may invoke the Discard() method to throw away changes made to the in-memory state.

The actual level of persistence provided will vary according to the IStorageProvider instance you use. For example if the DeleteGraph() method is not supported then Graph removals won't persist in the underlying store. Similarily an instance which is read-only will allow you to pull out existing graphs from the store but won't persist any changes.

The Contains() method of the underlying BaseGraphCollection has been overridden so that invoking Contains causes the Graph from the underlying store to be loaded if it exists, this means that operations like HasGraph() may be slower than expected or cause applications to stop while they wait to load data from the store.

SPARQL Query Behaviour

The exact SPARQL Query behaviour will depend on the capabilities of the underlying IStorageProvider instance. If it also implements the IQueryableStorage interface then its own SPARQL implementation will be used, note that if you try and make a SPARQL query but the in-memory view has not been synced (via a Flush() or Discard() call) prior to the query then an RdfQueryException will be thrown. If you want to make the query regardless you can do so by invoking the query method on the underlying store directly by accessing it via the UnderlyingStore property.

If the underlying store does not support SPARQL itself then SPARQL queries cannot be applied and a NotSupportedException will be thrown.

SPARQL Update Behaviour

Similarly to SPARQL Query support the SPARQL Update behaviour depends on whether the underlying IStorageProvider instance also implements the IUpdateableStorage interface. If it does then its own SPARQL implementation is used, otherwise a GenericUpdateProcessor will be used to approximate the SPARQL Update.

Please be aware that as with SPARQL Query if the in-memory view is not synced with the underlying store a SparqlUpdateException will be thrown.

Other Notes

It is possible for the in-memory view of the triple store to get out of sync with the underlying store if that store is being modified by other processes or other code not utilising the PersistentTripleStore instance that you have created. Currently there is no means to resync the in-memory view with the underlying view so you should be careful of using this class in scenarios where your underlying store may be modified.

ExecuteQuery(IRdfHandler, ISparqlResultsHandler, string)

Executes a SPARQL Query on the Triple Store processing the results using an appropriate handler from those provided.

Declaration

public void ExecuteQuery(IRdfHandler rdfHandler, ISparqlResultsHandler resultsHandler, string query)

Parameters

Type	Name	Description
IRdfHandler	rdfHandler	RDF Handler.
ISparqlResultsHandler	resultsHandler	Results Handler.
string	query	SPARQL Query as unparsed String.

Remarks

Persistence Behaviour

Note: This is a transactional implementation - this means that changes made are not persisted until you either call Flush() or you dispose of the instance. Alternatively you may invoke the Discard() method to throw away changes made to the in-memory state.

The actual level of persistence provided will vary according to the IStorageProvider instance you use. For example if the DeleteGraph() method is not supported then Graph removals won't persist in the underlying store. Similarily an instance which is read-only will allow you to pull out existing graphs from the store but won't persist any changes.

The Contains() method of the underlying BaseGraphCollection has been overridden so that invoking Contains causes the Graph from the underlying store to be loaded if it exists, this means that operations like HasGraph() may be slower than expected or cause applications to stop while they wait to load data from the store.

SPARQL Query Behaviour

The exact SPARQL Query behaviour will depend on the capabilities of the underlying IStorageProvider instance. If it also implements the IQueryableStorage interface then its own SPARQL implementation will be used, note that if you try and make a SPARQL query but the in-memory view has not been synced (via a Flush() or Discard() call) prior to the query then an RdfQueryException will be thrown. If you want to make the query regardless you can do so by invoking the query method on the underlying store directly by accessing it via the UnderlyingStore property.

If the underlying store does not support SPARQL itself then SPARQL queries cannot be applied and a NotSupportedException will be thrown.

SPARQL Update Behaviour

Similarly to SPARQL Query support the SPARQL Update behaviour depends on whether the underlying IStorageProvider instance also implements the IUpdateableStorage interface. If it does then its own SPARQL implementation is used, otherwise a GenericUpdateProcessor will be used to approximate the SPARQL Update.

Please be aware that as with SPARQL Query if the in-memory view is not synced with the underlying store a SparqlUpdateException will be thrown.

Other Notes

It is possible for the in-memory view of the triple store to get out of sync with the underlying store if that store is being modified by other processes or other code not utilising the PersistentTripleStore instance that you have created. Currently there is no means to resync the in-memory view with the underlying view so you should be careful of using this class in scenarios where your underlying store may be modified.

ExecuteUpdate(string)

Executes an Update against the Triple Store.

Declaration

public void ExecuteUpdate(string update)

Parameters

Type	Name	Description
string	update	SPARQL Update Command(s).

Remarks

As per the SPARQL 1.1 Update specification the command string may be a sequence of commands.

ExecuteUpdate(SparqlUpdateCommand)

Executes a single Update Command against the Triple Store.

Declaration

public void ExecuteUpdate(SparqlUpdateCommand update)

Parameters

Type	Name	Description
SparqlUpdateCommand	update	SPARQL Update Command.

Remarks

Persistence Behaviour

Note: This is a transactional implementation - this means that changes made are not persisted until you either call Flush() or you dispose of the instance. Alternatively you may invoke the Discard() method to throw away changes made to the in-memory state.

The actual level of persistence provided will vary according to the IStorageProvider instance you use. For example if the DeleteGraph() method is not supported then Graph removals won't persist in the underlying store. Similarily an instance which is read-only will allow you to pull out existing graphs from the store but won't persist any changes.

The Contains() method of the underlying BaseGraphCollection has been overridden so that invoking Contains causes the Graph from the underlying store to be loaded if it exists, this means that operations like HasGraph() may be slower than expected or cause applications to stop while they wait to load data from the store.

SPARQL Query Behaviour

The exact SPARQL Query behaviour will depend on the capabilities of the underlying IStorageProvider instance. If it also implements the IQueryableStorage interface then its own SPARQL implementation will be used, note that if you try and make a SPARQL query but the in-memory view has not been synced (via a Flush() or Discard() call) prior to the query then an RdfQueryException will be thrown. If you want to make the query regardless you can do so by invoking the query method on the underlying store directly by accessing it via the UnderlyingStore property.

If the underlying store does not support SPARQL itself then SPARQL queries cannot be applied and a NotSupportedException will be thrown.

SPARQL Update Behaviour

Similarly to SPARQL Query support the SPARQL Update behaviour depends on whether the underlying IStorageProvider instance also implements the IUpdateableStorage interface. If it does then its own SPARQL implementation is used, otherwise a GenericUpdateProcessor will be used to approximate the SPARQL Update.

Please be aware that as with SPARQL Query if the in-memory view is not synced with the underlying store a SparqlUpdateException will be thrown.

Other Notes

It is possible for the in-memory view of the triple store to get out of sync with the underlying store if that store is being modified by other processes or other code not utilising the PersistentTripleStore instance that you have created. Currently there is no means to resync the in-memory view with the underlying view so you should be careful of using this class in scenarios where your underlying store may be modified.

ExecuteUpdate(SparqlUpdateCommandSet)

Executes a set of Update Commands against the Triple Store.

Declaration

public void ExecuteUpdate(SparqlUpdateCommandSet updates)

Parameters

Type	Name	Description
SparqlUpdateCommandSet	updates	SPARQL Update Command Set.

Remarks

Persistence Behaviour

Note: This is a transactional implementation - this means that changes made are not persisted until you either call Flush() or you dispose of the instance. Alternatively you may invoke the Discard() method to throw away changes made to the in-memory state.

The actual level of persistence provided will vary according to the IStorageProvider instance you use. For example if the DeleteGraph() method is not supported then Graph removals won't persist in the underlying store. Similarily an instance which is read-only will allow you to pull out existing graphs from the store but won't persist any changes.

The Contains() method of the underlying BaseGraphCollection has been overridden so that invoking Contains causes the Graph from the underlying store to be loaded if it exists, this means that operations like HasGraph() may be slower than expected or cause applications to stop while they wait to load data from the store.

SPARQL Query Behaviour

The exact SPARQL Query behaviour will depend on the capabilities of the underlying IStorageProvider instance. If it also implements the IQueryableStorage interface then its own SPARQL implementation will be used, note that if you try and make a SPARQL query but the in-memory view has not been synced (via a Flush() or Discard() call) prior to the query then an RdfQueryException will be thrown. If you want to make the query regardless you can do so by invoking the query method on the underlying store directly by accessing it via the UnderlyingStore property.

If the underlying store does not support SPARQL itself then SPARQL queries cannot be applied and a NotSupportedException will be thrown.

SPARQL Update Behaviour

Similarly to SPARQL Query support the SPARQL Update behaviour depends on whether the underlying IStorageProvider instance also implements the IUpdateableStorage interface. If it does then its own SPARQL implementation is used, otherwise a GenericUpdateProcessor will be used to approximate the SPARQL Update.

Please be aware that as with SPARQL Query if the in-memory view is not synced with the underlying store a SparqlUpdateException will be thrown.

Other Notes

It is possible for the in-memory view of the triple store to get out of sync with the underlying store if that store is being modified by other processes or other code not utilising the PersistentTripleStore instance that you have created. Currently there is no means to resync the in-memory view with the underlying view so you should be careful of using this class in scenarios where your underlying store may be modified.

~PersistentTripleStore()

Finalizer which ensures that the instance is properly disposed of thereby persisting any outstanding changes to the underlying store

Declaration

protected ~PersistentTripleStore()

Remarks

If you do not wish to persist your changes you must call Discard() prior to disposing of this instance or allowing it to go out of scope such that the finalizer gets called

Flush()

Flushes any outstanding changes to the underlying store.

Declaration

public void Flush()

Remarks

Persistence Behaviour

Note: This is a transactional implementation - this means that changes made are not persisted until you either call Flush() or you dispose of the instance. Alternatively you may invoke the Discard() method to throw away changes made to the in-memory state.

The actual level of persistence provided will vary according to the IStorageProvider instance you use. For example if the DeleteGraph() method is not supported then Graph removals won't persist in the underlying store. Similarily an instance which is read-only will allow you to pull out existing graphs from the store but won't persist any changes.

The Contains() method of the underlying BaseGraphCollection has been overridden so that invoking Contains causes the Graph from the underlying store to be loaded if it exists, this means that operations like HasGraph() may be slower than expected or cause applications to stop while they wait to load data from the store.

SPARQL Query Behaviour

The exact SPARQL Query behaviour will depend on the capabilities of the underlying IStorageProvider instance. If it also implements the IQueryableStorage interface then its own SPARQL implementation will be used, note that if you try and make a SPARQL query but the in-memory view has not been synced (via a Flush() or Discard() call) prior to the query then an RdfQueryException will be thrown. If you want to make the query regardless you can do so by invoking the query method on the underlying store directly by accessing it via the UnderlyingStore property.

If the underlying store does not support SPARQL itself then SPARQL queries cannot be applied and a NotSupportedException will be thrown.

SPARQL Update Behaviour

Similarly to SPARQL Query support the SPARQL Update behaviour depends on whether the underlying IStorageProvider instance also implements the IUpdateableStorage interface. If it does then its own SPARQL implementation is used, otherwise a GenericUpdateProcessor will be used to approximate the SPARQL Update.

Please be aware that as with SPARQL Query if the in-memory view is not synced with the underlying store a SparqlUpdateException will be thrown.

Other Notes

It is possible for the in-memory view of the triple store to get out of sync with the underlying store if that store is being modified by other processes or other code not utilising the PersistentTripleStore instance that you have created. Currently there is no means to resync the in-memory view with the underlying view so you should be careful of using this class in scenarios where your underlying store may be modified.

Implements

INativelyQueryableStore

IUpdateableTripleStore

ITransactionalStore

ITripleStore

System.IDisposable

Extension Methods

Extensions.ToSafeString(object)

TripleStoreExtensions.LoadFromEmbeddedResource(ITripleStore, string, IStoreReader)

TripleStoreExtensions.LoadFromEmbeddedResource(ITripleStore, string)

TripleStoreExtensions.LoadFromFile(ITripleStore, string, IStoreReader)

TripleStoreExtensions.LoadFromFile(ITripleStore, string)

TripleStoreExtensions.LoadFromString(ITripleStore, string, IStoreReader)

TripleStoreExtensions.LoadFromString(ITripleStore, string)

TripleStoreExtensions.LoadFromUri(ITripleStore, Uri, IStoreReader, Loader)

TripleStoreExtensions.LoadFromUri(ITripleStore, Uri, IStoreReader)

TripleStoreExtensions.LoadFromUri(ITripleStore, Uri)

TripleStoreExtensions.SaveToFile(ITripleStore, string, IStoreWriter)

TripleStoreExtensions.SaveToFile(ITripleStore, string)

Extensions.AsEnumerable<T>(T)