[Nepomuk] Nepomuk Core - Questions & Patches

Sebastian Trüg trueg at kde.org
Mon May 24 10:15:44 CEST 2010


Hi Vishesh,

I don't really see how this can work. After all the same resource could
still be accessed in two different ways. For example we have this resource:

nepomuk:/res/foobar
    nao:identifier "foobar" .

Now the code:

Resource r1( QUrl("nepomuk:/res/foobar" ) );
Resource r2( "foobar" );

At this point determineUri has not been called for any resource yet and
as far as RM is concerned those are different resources with 2 different
RDs.

Be aware though that I did not look at your patch in detail yet. I will
do that later. So I might have missed something. :)

Cheers,
Sebastian

On 05/23/2010 05:54 PM, Vishesh Handa wrote:
> 
> On Sun, May 23, 2010 at 8:20 PM, Sebastian Trüg <trueg at kde.org
> <mailto:trueg at kde.org>> wrote:
> 
>     On 05/23/2010 04:23 PM, Vishesh Handa wrote:
>     >     > One way of solving both the problems is to derive
>     ResourceData from
>     >     > QObject. And then call deleteLater() instead of "delete
>     this". (Patch
>     >     > attached)
>     >
>     >     oh, no, please don't. Totally useless overhead. It is much
>     simpler to
>     >     make the mutex recursive.
>     >
>     >
>     > Well then we need a better way of solving the "delete this" problem.
>     > When you say moving "it" into Resource, do you mean determineUri() or
>     > replaceWith() ?
> 
>     I mean all calls of determineUri().
>     Example:
>     ResourceData::removeProperty calls determineUri. Instead determineUri
>     should be called in Resource::removeProperty.
> 
> 
> I'm sorry. I don't understand. Isn't it the same thing? If A calls B or
> B is called inside A?
>  
> 
>     The only problem here is load. But I recently thought that it could be
>     merged into determineUri (or the other way around). After all most
>     resources do not have more than - say - 20 properties. That is quickly
>     loaded and would avoid performing yet another query. What I mean is that
>     in determineUri
> 
>     select distinct ?r ?o where {
>     { ?r nie:url <uri> . }
>     UNION { <uri> ?p ?o . } } LIMIT 1
> 
>     could become something like
> 
>     select distinct ?r ?pp ?oo where {
>     { ?r nie:url <uri> .
>     ?r ?pp ?oo . FILTER(?r!=<uri> . }
>     UNION { <uri> ?p ?o . <uri> ?pp ?oo . }
> 
>     to determine the URI AND load all properties at the same time.
>     Just an idea I had when I thought about ways to spped it all up...
> 
> 
> Seems logical. But then you call determineUri everywhere? I guess we
> could make it determineAndLoad(). :-)
> 
> ---------------------------
> 
> I had another idea on how to get rid of the proxy mess. I was going to
> tell you about it later, as its aim was to get rid of the nasty lists
> and determineUri mess, but it seems as though it would solve the proxy
> problem as well. (Nice side effect!)
> 
> The ResourceManagerPrivate has 2 sets of lists. I'm going to call them
> INIT-LIST (m_initializedData) and the HALF-INIT list (m_uriKickoffData &
> m_idKickoffData). Whenever a Resource is created by the RMP::data()
> function, it checks if it is present INIT-LIST or HALF-init list, and
> accordingly gives us a RD (ResourceData).
> 
> A RD can go into the HALF-INIT lists in 4 ways - (look at determineUri)
> --- KickOffId
> ------- nepomuk://res/ stored as a string
> ------- nao:identifier
> 
> --- KickOffUri
> -------- nie:url
> -------- nepomuk://res/
> 
> *Proposal :*
> Remove the KickOffId completely. And make KickOffUri contain the
> nao:identifier as well. When determineUri is being called, say
> m_kickOffUri is the nepomuk resource uri, it should add itself to the
> INIT-LIST and it should add all other ways of getting Initialized to the
> HALF-INIT list ( nao:identifier and nie:url ) This way RMP:data() will
> always returns the correct RD* and a proxy wouldn't be required.
> 
> determineUri would be a lot simpler -
> 
> if( m_kickOffUri.isValid() ) {
>       // check for nepomuk://res/
>       // check for nie:url and the filex crap which I don't understand
> } else {
>      // check for nao:identifier
> }
> 
> An additional thing we could do is to make removeProperty() removing the
> corresponding RD from the HALF-INIT list if the property being removed
> is nao:identifier or nie::url. (addProperty should check for the same)/
> 
> I hope I've been clear enough.
> 
> - Vishesh Handa
> 
> 
>     Cheers,
>     Sebastian
> 
> 


More information about the Nepomuk mailing list