[Nepomuk] Refactoring for Soprano 3

Sebastian Trüg trueg at kde.org
Wed Oct 21 10:08:05 CEST 2009

On Tuesday 20 October 2009 21:52:34 Greg Beauchesne wrote:
> >> 3. Pooled: NO, private data: YES - Node data may or may not be
> >> immediately realized. This type is the fastest when used with single
> >> Models. When Model boundaries are crossed, the optimization data is
> >> lost/ignored, and the Node is just treated like #1. Client code does not
> >> create this directly, but if it knows the target Model in advance, it
> >> could ask the Model to attach its private data.
> >
> > 
> > I don't really get the last sentence. Why and how would a client ask a
> > Model  to attach its internal data. I thought that a backend like redland
> > would simply always use its internal node representation for lazy
> > conversion of the node data.
> Much like the client code pre-pooling an otherwise constant Node for use
> with multiple models, it could be more efficient to pre-optimize a Node
> for a series of queries on a particular Model.
> Example:
> Node myNode(QUrl("http://this.uri/gets/reused"));
> myNode = model->internalize(myNode);
> Q_FOREACH (Node subj, subjList) {
>     StatementIterator it = model->listStatements(subj, myNode, Node());
>     ...
> }
> Without internalize() above, the "http://this.uri/gets/reused" has to be
>  reprocessed for every call to listStatements().

right, ok. I keep forgetting about the listStatements case. This sounds 
reasonable indeed.

I think it is time to start a wiki page or something to gather all the ideas.
I will see about that.


More information about the Nepomuk mailing list