[Nepomuk] Nepomuk Core - Questions & Patches

[Sebastian Trüg]

On 05/24/2010 11:20 AM, Vishesh Handa wrote:
> On Mon, May 24, 2010 at 1:45 PM, Sebastian Trüg <trueg at kde.org
> <mailto:trueg at kde.org>> wrote:
> 
>     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.
> 
> 
> You're right. I forgot that determineUri has to be called at least once.
> :-( I think we should add a test for this.

Oh, I thought there was a test case for that.... weird.

> Hmm, so we still need some kind of proxies. I guess it's time to combine
> determineUri() and load().

Yeah... I think merging determineUri into load and calling it simply
load() is perfectly fine. The that method would only be called from
Resource but never in ResourceData methods.

Cheers,
Sebastian

> - Vishesh Handa
>  
> 
> 
>     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>
>     > <mailto: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
>     >
>     >
> 
>