Class BaseTransactionalQuadDataset
Abstract Base class for quad datasets that support transactions.
Inherited Members
Namespace: VDS.RDF.Query.Datasets
Assembly: dotNetRdf.dll
Syntax
public abstract class BaseTransactionalQuadDataset : BaseQuadDataset, ISparqlDataset, ITripleIndex
Remarks
The Transaction implementation of dotNetRDF is based upon a MRSW concurrency model, since only one writer may be active changes are immediately pushed to the dataset and visible within the transaction and they are committed or rolled back when Flush() or Discard() are called.
So in practical terms it is perfectly OK for the storage to be updated during a transaction because if the transaction fails the changes will be rolled back because all changes are stored in-memory until the end of the transaction. This may not be an ideal transaction model for all scenarios so you may wish to implement your own version of transactions or code your implementations of the abstract methods accordingly to limit actual persistence to the end of a transaction.
Constructors
| Improve this Doc View SourceBaseTransactionalQuadDataset()
Creates a Transactional Quad Dataset.
Declaration
public BaseTransactionalQuadDataset()
Remarks
The Transaction implementation of dotNetRDF is based upon a MRSW concurrency model, since only one writer may be active changes are immediately pushed to the dataset and visible within the transaction and they are committed or rolled back when Flush() or Discard() are called.
So in practical terms it is perfectly OK for the storage to be updated during a transaction because if the transaction fails the changes will be rolled back because all changes are stored in-memory until the end of the transaction. This may not be an ideal transaction model for all scenarios so you may wish to implement your own version of transactions or code your implementations of the abstract methods accordingly to limit actual persistence to the end of a transaction.
BaseTransactionalQuadDataset(bool)
Creates a Transactional Quad Dataset.
Declaration
public BaseTransactionalQuadDataset(bool unionDefaultGraph)
Parameters
Type | Name | Description |
---|---|---|
System.Boolean | unionDefaultGraph | Sets whether the default graph should be the union of all graphs. |
Remarks
The Transaction implementation of dotNetRDF is based upon a MRSW concurrency model, since only one writer may be active changes are immediately pushed to the dataset and visible within the transaction and they are committed or rolled back when Flush() or Discard() are called.
So in practical terms it is perfectly OK for the storage to be updated during a transaction because if the transaction fails the changes will be rolled back because all changes are stored in-memory until the end of the transaction. This may not be an ideal transaction model for all scenarios so you may wish to implement your own version of transactions or code your implementations of the abstract methods accordingly to limit actual persistence to the end of a transaction.
BaseTransactionalQuadDataset(Uri)
Creates a Transactional Quad Dataset.
Declaration
public BaseTransactionalQuadDataset(Uri defaultGraphUri)
Parameters
Type | Name | Description |
---|---|---|
System.Uri | defaultGraphUri | Default Graph URI. |
Remarks
The Transaction implementation of dotNetRDF is based upon a MRSW concurrency model, since only one writer may be active changes are immediately pushed to the dataset and visible within the transaction and they are committed or rolled back when Flush() or Discard() are called.
So in practical terms it is perfectly OK for the storage to be updated during a transaction because if the transaction fails the changes will be rolled back because all changes are stored in-memory until the end of the transaction. This may not be an ideal transaction model for all scenarios so you may wish to implement your own version of transactions or code your implementations of the abstract methods accordingly to limit actual persistence to the end of a transaction.
BaseTransactionalQuadDataset(IRefNode)
Creates a transactional quad dataset.
Declaration
public BaseTransactionalQuadDataset(IRefNode defaultGraphName)
Parameters
Type | Name | Description |
---|---|---|
IRefNode | defaultGraphName | Default graph name. |
Remarks
The Transaction implementation of dotNetRDF is based upon a MRSW concurrency model, since only one writer may be active changes are immediately pushed to the dataset and visible within the transaction and they are committed or rolled back when Flush() or Discard() are called.
So in practical terms it is perfectly OK for the storage to be updated during a transaction because if the transaction fails the changes will be rolled back because all changes are stored in-memory until the end of the transaction. This may not be an ideal transaction model for all scenarios so you may wish to implement your own version of transactions or code your implementations of the abstract methods accordingly to limit actual persistence to the end of a transaction.
Properties
| Improve this Doc View Sourcethis[Uri]
Gets a Graph from the dataset.
Declaration
[Obsolete("Replaced by this[IRefNode]")]
public override IGraph this[Uri graphUri] { get; }
Parameters
Type | Name | Description |
---|---|---|
System.Uri | graphUri | Graph URI. |
Property Value
Type | Description |
---|---|
IGraph |
Overrides
Remarks
The Transaction implementation of dotNetRDF is based upon a MRSW concurrency model, since only one writer may be active changes are immediately pushed to the dataset and visible within the transaction and they are committed or rolled back when Flush() or Discard() are called.
So in practical terms it is perfectly OK for the storage to be updated during a transaction because if the transaction fails the changes will be rolled back because all changes are stored in-memory until the end of the transaction. This may not be an ideal transaction model for all scenarios so you may wish to implement your own version of transactions or code your implementations of the abstract methods accordingly to limit actual persistence to the end of a transaction.
this[IRefNode]
Gets the graph with the given name from the dataset.
Declaration
public override IGraph this[IRefNode graphName] { get; }
Parameters
Type | Name | Description |
---|---|---|
IRefNode | graphName | Graph name. |
Property Value
Type | Description |
---|---|
IGraph |
Overrides
Remarks
This property need only return a read-only view of the Graph, code which wishes to modify Graphs should use the GetModifiableGraph() method to guarantee a Graph they can modify and will be persisted to the underlying storage.
Methods
| Improve this Doc View SourceAddGraph(IGraph)
Adds a Graph to the Dataset.
Declaration
public override sealed bool AddGraph(IGraph g)
Parameters
Type | Name | Description |
---|---|---|
IGraph | g | Graph to add. |
Returns
Type | Description |
---|---|
System.Boolean |
Overrides
Remarks
The Transaction implementation of dotNetRDF is based upon a MRSW concurrency model, since only one writer may be active changes are immediately pushed to the dataset and visible within the transaction and they are committed or rolled back when Flush() or Discard() are called.
So in practical terms it is perfectly OK for the storage to be updated during a transaction because if the transaction fails the changes will be rolled back because all changes are stored in-memory until the end of the transaction. This may not be an ideal transaction model for all scenarios so you may wish to implement your own version of transactions or code your implementations of the abstract methods accordingly to limit actual persistence to the end of a transaction.
AddGraphInternal(IGraph)
Adds a Graph to the Dataset.
Declaration
protected abstract bool AddGraphInternal(IGraph g)
Parameters
Type | Name | Description |
---|---|---|
IGraph | g | Graph to add. |
Returns
Type | Description |
---|---|
System.Boolean |
Remarks
The Transaction implementation of dotNetRDF is based upon a MRSW concurrency model, since only one writer may be active changes are immediately pushed to the dataset and visible within the transaction and they are committed or rolled back when Flush() or Discard() are called.
So in practical terms it is perfectly OK for the storage to be updated during a transaction because if the transaction fails the changes will be rolled back because all changes are stored in-memory until the end of the transaction. This may not be an ideal transaction model for all scenarios so you may wish to implement your own version of transactions or code your implementations of the abstract methods accordingly to limit actual persistence to the end of a transaction.
Discard()
Ensures that any changes to the Dataset (if any) are discarded.
Declaration
public override sealed void Discard()
Overrides
Remarks
Rollsback the Active Transaction.
DiscardInternal()
Allows the derived dataset to take any post-Discard() actions required.
Declaration
protected virtual void DiscardInternal()
Remarks
The Transaction implementation of dotNetRDF is based upon a MRSW concurrency model, since only one writer may be active changes are immediately pushed to the dataset and visible within the transaction and they are committed or rolled back when Flush() or Discard() are called.
So in practical terms it is perfectly OK for the storage to be updated during a transaction because if the transaction fails the changes will be rolled back because all changes are stored in-memory until the end of the transaction. This may not be an ideal transaction model for all scenarios so you may wish to implement your own version of transactions or code your implementations of the abstract methods accordingly to limit actual persistence to the end of a transaction.
Flush()
Ensures that any changes to the Dataset (if any) are flushed to the underlying Storage.
Declaration
public override sealed void Flush()
Overrides
Remarks
Commits the Active Transaction.
FlushInternal()
Allows the derived dataset to take any post-Flush() actions required.
Declaration
protected virtual void FlushInternal()
Remarks
The Transaction implementation of dotNetRDF is based upon a MRSW concurrency model, since only one writer may be active changes are immediately pushed to the dataset and visible within the transaction and they are committed or rolled back when Flush() or Discard() are called.
So in practical terms it is perfectly OK for the storage to be updated during a transaction because if the transaction fails the changes will be rolled back because all changes are stored in-memory until the end of the transaction. This may not be an ideal transaction model for all scenarios so you may wish to implement your own version of transactions or code your implementations of the abstract methods accordingly to limit actual persistence to the end of a transaction.
GetModifiableGraph(Uri)
Gets a Graph from the Dataset that can be modified.
Declaration
[Obsolete("Replaced by GetModifiableGraph(IRefNode)")]
public override sealed IGraph GetModifiableGraph(Uri graphUri)
Parameters
Type | Name | Description |
---|---|---|
System.Uri | graphUri | Graph URI. |
Returns
Type | Description |
---|---|
IGraph |
Overrides
Remarks
The Transaction implementation of dotNetRDF is based upon a MRSW concurrency model, since only one writer may be active changes are immediately pushed to the dataset and visible within the transaction and they are committed or rolled back when Flush() or Discard() are called.
So in practical terms it is perfectly OK for the storage to be updated during a transaction because if the transaction fails the changes will be rolled back because all changes are stored in-memory until the end of the transaction. This may not be an ideal transaction model for all scenarios so you may wish to implement your own version of transactions or code your implementations of the abstract methods accordingly to limit actual persistence to the end of a transaction.
GetModifiableGraph(IRefNode)
Gets the Graph with the given name from the Dataset.
Declaration
public override IGraph GetModifiableGraph(IRefNode graphName)
Parameters
Type | Name | Description |
---|---|---|
IRefNode | graphName | Graph name. |
Returns
Type | Description |
---|---|
IGraph |
Overrides
Remarks
Graphs returned from this method must be modifiable and the Dataset must guarantee that when it is Flushed or Disposed of that any changes to the Graph are persisted.
Exceptions
Type | Condition |
---|---|
System.NotSupportedException | May be thrown if the Dataset is immutable i.e. Updates not supported. |
GetModifiableGraphInternal(IRefNode)
Gets a Graph from the Dataset that can be modified transactionally.
Declaration
protected abstract ITransactionalGraph GetModifiableGraphInternal(IRefNode graphUri)
Parameters
Type | Name | Description |
---|---|---|
IRefNode | graphUri | Graph URI. |
Returns
Type | Description |
---|---|
ITransactionalGraph |
Remarks
The Transaction implementation of dotNetRDF is based upon a MRSW concurrency model, since only one writer may be active changes are immediately pushed to the dataset and visible within the transaction and they are committed or rolled back when Flush() or Discard() are called.
So in practical terms it is perfectly OK for the storage to be updated during a transaction because if the transaction fails the changes will be rolled back because all changes are stored in-memory until the end of the transaction. This may not be an ideal transaction model for all scenarios so you may wish to implement your own version of transactions or code your implementations of the abstract methods accordingly to limit actual persistence to the end of a transaction.
RemoveGraph(Uri)
Removes a Graph from the Dataset.
Declaration
[Obsolete("Replaced by RemoveGraph(IRefNode)")]
public override sealed bool RemoveGraph(Uri graphUri)
Parameters
Type | Name | Description |
---|---|---|
System.Uri | graphUri | Graph URI. |
Returns
Type | Description |
---|---|
System.Boolean |
Overrides
Remarks
The Transaction implementation of dotNetRDF is based upon a MRSW concurrency model, since only one writer may be active changes are immediately pushed to the dataset and visible within the transaction and they are committed or rolled back when Flush() or Discard() are called.
So in practical terms it is perfectly OK for the storage to be updated during a transaction because if the transaction fails the changes will be rolled back because all changes are stored in-memory until the end of the transaction. This may not be an ideal transaction model for all scenarios so you may wish to implement your own version of transactions or code your implementations of the abstract methods accordingly to limit actual persistence to the end of a transaction.
RemoveGraph(IRefNode)
Removes a Graph from the Dataset.
Declaration
public override bool RemoveGraph(IRefNode graphName)
Parameters
Type | Name | Description |
---|---|---|
IRefNode | graphName | Graph name. |
Returns
Type | Description |
---|---|
System.Boolean |
Overrides
Remarks
The Transaction implementation of dotNetRDF is based upon a MRSW concurrency model, since only one writer may be active changes are immediately pushed to the dataset and visible within the transaction and they are committed or rolled back when Flush() or Discard() are called.
So in practical terms it is perfectly OK for the storage to be updated during a transaction because if the transaction fails the changes will be rolled back because all changes are stored in-memory until the end of the transaction. This may not be an ideal transaction model for all scenarios so you may wish to implement your own version of transactions or code your implementations of the abstract methods accordingly to limit actual persistence to the end of a transaction.
Exceptions
Type | Condition |
---|---|
System.NotSupportedException | May be thrown if the Dataset is immutable i.e. Updates not supported. |
RemoveGraphInternal(IRefNode)
Removes a graph from the dataset.
Declaration
protected abstract bool RemoveGraphInternal(IRefNode graphName)
Parameters
Type | Name | Description |
---|---|---|
IRefNode | graphName | Graph name. |
Returns
Type | Description |
---|---|
System.Boolean |
Remarks
The Transaction implementation of dotNetRDF is based upon a MRSW concurrency model, since only one writer may be active changes are immediately pushed to the dataset and visible within the transaction and they are committed or rolled back when Flush() or Discard() are called.
So in practical terms it is perfectly OK for the storage to be updated during a transaction because if the transaction fails the changes will be rolled back because all changes are stored in-memory until the end of the transaction. This may not be an ideal transaction model for all scenarios so you may wish to implement your own version of transactions or code your implementations of the abstract methods accordingly to limit actual persistence to the end of a transaction.