com.bigdata.rdf.magic
Class MagicRelation

java.lang.Object
  com.bigdata.relation.AbstractResource<IRelation<E>>
      com.bigdata.relation.AbstractRelation<IMagicTuple>
          com.bigdata.rdf.magic.MagicRelation

All Implemented Interfaces:

IMutableRelation<IMagicTuple>, IMutableResource<IRelation<IMagicTuple>>, IRelation<IMagicTuple>, ILocatableResource<IRelation<IMagicTuple>>

public class MagicRelation
extends AbstractRelation<IMagicTuple>

Nested Class Summary

Nested classes/interfaces inherited from class com.bigdata.relation.AbstractResource

AbstractResource.Options

Field Summary

protected static boolean	INFO
protected static org.apache.log4j.Logger	log

Constructor Summary

MagicRelation(IIndexManager indexManager, String namespace, Long timestamp, Properties properties)

Method Summary

void	create() Create any logically contained resources (relations, indices).
long	delete(IChunkedOrderedIterator<IMagicTuple> itr) Remove elements from the relation.
void	destroy() Destroy any logically contained resources (relations, indices).
MagicAccessPath	getAccessPath(IKeyOrder<IMagicTuple> keyOrder)
MagicAccessPath	getAccessPath(IKeyOrder<IMagicTuple> keyOrder, IPredicate<IMagicTuple> predicate) Core impl.
IAccessPath<IMagicTuple>	getAccessPath(IPredicate<IMagicTuple> predicate) Return the best IAccessPath for a relation given a predicate with zero or more unbound variables.
int	getArity()
AbstractTripleStore	getContainer() Strengthened return type.
Class<IMagicTuple>	getElementClass() Return the class for the generic type of this relation.
Set<String>	getIndexNames() Return the fully qualified name of each index maintained by this relation.
MagicKeyOrder	getKeyOrder(IPredicate<IMagicTuple> predicate) Return the MagicKeyOrder for the given predicate.
protected MagicKeyOrder[]	getKeyOrders() Really need to keep this in the global row store or something to avoid re-calculating all the time.
protected IndexMetadata	getMagicTupleIndexMetadata(MagicKeyOrder keyOrder)
MagicKeyOrder	getPrimaryKeyOrder()
long	insert(IChunkedOrderedIterator<IMagicTuple> itr) Write elements on the relation.
long	insert(IMagicTuple[] tuples, int numTuples)
IMagicTuple	newElement(IPredicate<IMagicTuple> predicate, IBindingSet bindingSet) Create and return a new element.

Methods inherited from class com.bigdata.relation.AbstractRelation

getFQN, getIndex, getIndex, newIndexMetadata

Methods inherited from class com.bigdata.relation.AbstractResource

acquireExclusiveLock, getChunkCapacity, getChunkOfChunksCapacity, getChunkTimeout, getContainerNamespace, getExecutorService, getFullyBufferedReadThreshold, getIndexManager, getMaxParallelSubqueries, getNamespace, getProperties, getProperty, getProperty, getTimestamp, isForceSerialExecution, isNestedSubquery, toString, unlock

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait

Methods inherited from interface com.bigdata.relation.IRelation

getExecutorService, getIndexManager

Methods inherited from interface com.bigdata.relation.locator.ILocatableResource

getContainerNamespace, getNamespace, getTimestamp

Field Detail

log

protected static final org.apache.log4j.Logger log

INFO

protected static final boolean INFO

Constructor Detail

MagicRelation

public MagicRelation(IIndexManager indexManager,
                     String namespace,
                     Long timestamp,
                     Properties properties)

Method Detail

getArity

public int getArity()

create

public void create()

Description copied from interface: IMutableResource

Create any logically contained resources (relations, indices).

Specified by:

create in interface IMutableResource<IRelation<IMagicTuple>>

Overrides:

create in class AbstractResource<IRelation<IMagicTuple>>

destroy

public void destroy()

Description copied from interface: IMutableResource

Destroy any logically contained resources (relations, indices).

Specified by:

destroy in interface IMutableResource<IRelation<IMagicTuple>>

Overrides:

destroy in class AbstractResource<IRelation<IMagicTuple>>

getKeyOrders

protected MagicKeyOrder[] getKeyOrders()

Really need to keep this in the global row store or something to avoid re-calculating all the time.

Returns:

getMagicTupleIndexMetadata

protected IndexMetadata getMagicTupleIndexMetadata(MagicKeyOrder keyOrder)

delete

public long delete(IChunkedOrderedIterator<IMagicTuple> itr)

Description copied from interface: IMutableRelation

Remove elements from the relation.

Parameters:

itr - An iterator visiting the elements to be removed. Existing elements in the relation having a key equal to the key formed from the visited elements will be removed from the relation.

Returns:

The #of elements that were actually removed from the relation.

insert

public long insert(IChunkedOrderedIterator<IMagicTuple> itr)

Description copied from interface: IMutableRelation

Write elements on the relation.

Parameters:

itr - An iterator visiting the elements to be written.

Returns:

The #of elements that were actually written on the relation.

insert

public long insert(IMagicTuple[] tuples,
                   int numTuples)

getAccessPath

public IAccessPath<IMagicTuple> getAccessPath(IPredicate<IMagicTuple> predicate)

Description copied from interface: IRelation

Return the best IAccessPath for a relation given a predicate with zero or more unbound variables.

If there is an IIndex that directly corresponeds to the natural order implied by the variable pattern on the predicate then the access path should use that index. Otherwise you should choose the best index given the constraints and make sure that the IAccessPath incorporates additional filters that will allow you to filter out the irrelevant ITuples during the scan - this is very important when the index is remote!

If there are any IElementFilters then the access path MUST incorporate those constraints such that only elements that satisify the constraints may be visited.

Whether the constraints arise because of the lack of a perfect index for the access path or because they were explicitly specified for the IPredicate, those constraints should be translated into constraints imposed on the underlying ITupleIterator and sent with it to be evaluated local to the data.

Note: Filters should be specified when the IAccessPath is constructed so that they will be evalated on the data service rather than materializing the elements and then filtering then. This can be accomplished by adding the filter as a constraint on the predicate when specifying the access path.

Parameters:

predicate - The constraint on the elements to be visited.

Returns:

The best IAccessPath for that IPredicate.

getPrimaryKeyOrder

public MagicKeyOrder getPrimaryKeyOrder()

getAccessPath

public MagicAccessPath getAccessPath(IKeyOrder<IMagicTuple> keyOrder)

getKeyOrder

public MagicKeyOrder getKeyOrder(IPredicate<IMagicTuple> predicate)

Return the MagicKeyOrder for the given predicate.

Parameters:

predicate - The predicate.

Returns:

The MagicKeyOrder

getAccessPath

public MagicAccessPath getAccessPath(IKeyOrder<IMagicTuple> keyOrder,
                                     IPredicate<IMagicTuple> predicate)

Core impl.

Note: This method is NOT cached. See getAccessPath(IPredicate).

Parameters:

keyOrder - The natural order of the selected index (this identifies the index).

predicate - The predicate specifying the query constraint on the access path.

Returns:

The access path. FIXME This does not touch the cache. Track down the callers. I imagine that these are mostly SPO access path scans, but they could also be scans on the POS or OSP indices. What we really want is a method with the signature getAccessPath(keyOrder,filter), where the filter is optional. This method should cache by the keyOrder, which implies that we want to either verify or layer on the filter if we will be reusing the cached access path with different filter values.

The application SHOULD NOT specify both the predicate and the keyOrder since they are less likely to make the right choice, but it is reasonable to specify the keyOrder for bulk copy, dump, and some other modestly low level things and when only a single access path is used, then of course we need to specify that access path (several things use a temporary triple store with only the SPO access path).

getContainer

public AbstractTripleStore getContainer()

Strengthened return type.

Overrides:

getContainer in class AbstractResource<IRelation<IMagicTuple>>

Returns:

The container -or- null if there is no container.

getIndexNames

public Set<String> getIndexNames()

Description copied from interface: IRelation

Return the fully qualified name of each index maintained by this relation.

Returns:

An immutable set of the index names for the relation.

newElement

public IMagicTuple newElement(IPredicate<IMagicTuple> predicate,
                              IBindingSet bindingSet)

Description copied from interface: IRelation

Create and return a new element. The element is constructed from the predicate given the bindings. Typically, this is used when generating an ISolution for an IRule during either a query or mutation operations. The element is NOT inserted into the relation.

Parameters:

predicate - The predicate that is the head of some IRule.

bindingSet - A set of bindings for that IRule.

Returns:

The new element.

getElementClass

public Class<IMagicTuple> getElementClass()

Description copied from interface: IRelation

Return the class for the generic type of this relation. This information is used to dynamically create arrays of that generic type.